Stream retry after partial output can duplicate a turn and re-run tool calls

[iceteaSA]

Found during a source audit of 9bf8f4c. Verified by reading the code; not yet observed in the wild. A PR is incoming.

What happens

packages/opencode/src/ws.ts tracks whether any output has already reached the consumer in a local emitted flag, set right after controller.enqueue(...) (line 506).

The rate-limit interception path checks that flag before deciding whether a failure is retryable, and deliberately refuses to retry once output has gone out:

// side-effecting tools, and double-bill — so end the turn WITHOUT a
// retry. The mark still steers the next turn off this account.
closeCompleted()

The two transport-failure handlers never consult it:

function onError(error: Event) {
  invalidate(new ResponseStreamError(errorMessage(error), { cause: error }))
}

function onClose(event: CloseEvent) {
  if (completed) return
  invalidate(new ResponseStreamError(closeMessage(...)))
}

invalidate() (lines 304-310) calls controller.error(error), and ResponseStreamError is the marker that says the turn may be re-sent. resetIdleTimeout (line 312+) reaches invalidate the same way.

So a socket error, an early close, or an idle timeout after partial output has already been delivered can still surface as retryable.

Impact

The turn can be replayed after the user has already received part of it: duplicated text, side-effecting tool calls run a second time, and the turn billed twice.

Trigger

Any output event, followed by a socket error / close / idle timeout before response.completed.

Note for whoever fixes it

Routing these paths into closeCompleted() is not the fix. That enqueues data: [DONE] and closes normally, so a turn that died halfway would look complete — trading duplication for silent truncation, which is harder to notice.

A pre-output failure should stay retryable. A post-output failure needs to fail visibly and non-retryably.

Affected

packages/opencode/src/ws.ts at 9bf8f4c, lines 304-310, 497-506, 540-555.

[iceteaSA]

Correction: the surface is wider than I first reported. I named three paths; there are five.

An independent review of our fix enumerated every invalidate caller and every consumer-visible error construction, and proved two more with live probes:

• ws.ts:340 — an unexpected binary frame calls invalidate unconditionally. Probe output_text.delta → binary frame produced a retryable APICallError after output.
• ws.ts:403 — a throwing onRetryableTerminal callback lands in invalidate. This one is reachable in production: the connection-limit callback is such a path. Probe output_text.delta → websocket_connection_limit_reached produced a retryable error.
• ws.ts:415-430 — parseWrappedError always constructs an APICallError, and the installed AI SDK treats 408/409/429/500/503 as retryable, so a wrapped 503 after output replays regardless of the emitted flag. Probe output_text.delta → wrapped 503 confirmed it.

So the defect is better stated as a class than as three sites: any failure path that raises a retryable marker without consulting emitted. The fix in progress gates all five and enumerates every construction site.

Two things the same review confirmed are already correct, in case they look suspicious while reading:

• ws.ts:610 (synchronous socket.send failure) does not need the gate — production callbacks never return a replacement socket, so that send always precedes output.
• Counting post-output transport failures toward streamRetries is right. The socket genuinely failed, and a successful terminal response resets the counter.