Spurious "Tool execution aborted" on the slower of two tools dispatched in the same step #37364

Description

When two tool calls are dispatched close together within a single assistant step (a parallel batch), the slower of the two intermittently returns the generic Tool execution aborted, even though nothing was actually cancelled and the tool would otherwise have succeeded. The fast call always completes.

I traced this to SessionProcessor.cleanup() in packages/opencode/src/session/processor.ts. When the per-step stream drains, cleanup waits only 250 ms for still-pending tool calls:

• processor.ts:582-586 — Deferred.await(call.done).pipe(Effect.timeout("250 millis"), Effect.ignore)
• processor.ts:610-626 — anything still tracked after that grace window is hard-stamped error: "Tool execution aborted" (interrupted: true).

So if a co-dispatched tool needs longer than ~250 ms to settle, it gets stamped as aborted.

I confirmed it is not a real cancellation by instrumenting the teardown. In every reproduction the stamped call showed:

• aborted=false (no fiber interrupt)
• no assistantError (no provider/stream error)
• finish=tool-calls
• and no late tool-result ever arrived for the stamped call

In other words, the step is treated as finished while a slower tool from the same step is still in flight, and cleanup's 250 ms grace expires before it settles. This matches the "second of two calls" pattern already noted in #18757.

Raising the timeout only lowers the frequency, and awaiting longer would hang teardown on a genuine user-abort — so the real fix likely belongs at the step boundary (don't consider the step finished / don't stamp while tool calls dispatched in that step are still executing) rather than in the grace window. Filing this so the root cause is tracked separately from the generic symptom reports.

Related: #18757 (and its duplicates #17159, #11079, #26063, #31459). Note PR #35268 fixes a different branch (a tool-error arriving before tool-call), not this finish-before-result case.

Reproduces across transports — the common factor is one fast + one slow call issued together:

• two native tools (bash echo paired with a webfetch of a large page)
• two remote HTTP MCP tools
• two local stdio MCP tools

It does not reproduce with genuinely sequential calls (one tool per step).

Plugins

None.

OpenCode version

1.18.2 (reproduced on a local dev build of the current dev branch; also reported on 1.2.x–1.17.x in #18757).

Steps to reproduce

1. In a single assistant turn, dispatch two tool calls at once: one fast (bash echo hi) and one slow (webfetch of a large page, e.g. a long Wikipedia article).
2. Check the tool results — the slower call intermittently returns exactly Tool execution aborted.
3. Repeat a handful of times. It is timing-dependent (~250 ms threshold), so it hits some rounds and not others.

Operating System

macOS 26.5.1