fix(session): retry empty unknown-finish streams instead of stopping

[moritzscheele]

Issue for this PR

Closes #41469
Closes #43622

Type of change

• Bug fix

What does this PR do?

A provider or gateway can close the SSE stream cleanly without sending content or a finish frame. The AI SDK then reports a step finish reason of unknown with zero usage. The processor persists finish=unknown, and the prompt loop only excludes tool-calls from its exit check, so the turn ends silently and looks like a normal completion.

I hit this repeatedly on opencode/x-preview-f-free: 189 logged stream error entries in one day, and many assistant messages stored with finish=unknown, zero output tokens, and no error field. Their parts contain only step-start + step-finish(reason=unknown), which shows the stream ended cleanly instead of throwing.

The fix fails such streams after a clean drain: if finish === "unknown" and output tokens are zero (and compaction did not request the early stop), process fails with ProviderError.ResponseStreamError. MessageV2.fromError already maps that to a retryable APIError, so the existing SessionRetry.policy applies backoff and retries, and halt sets a visible error if all retries fail. Streams that end unknown but produced real output are untouched.

Note: #41466 addresses the same problem. This PR was developed independently and keeps the change smaller by reusing the existing error type instead of adding a new one.

How did you verify your code works?

• bun run typecheck passes
• bun test test/session/processor-effect.test.ts test/session/retry.test.ts: 77 pass
• Rebuilt the desktop app with this patch and ran it against the same flaky gateway; empty streams now trigger the visible retry flow instead of ending the turn
• Verification with long-running tasks is still being performed; I will post results here

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found several related PRs that address similar issues with empty/truncated provider streams and unknown finish reasons:

Potentially Related PRs

1. PR fix(opencode): retry empty unknown responses #41466 - fix(opencode): retry empty unknown responses

   • Directly related to retrying empty unknown responses

2. PR fix(opencode): surface truncated turns instead of ending the loop #40142 - fix(opencode): surface truncated turns instead of ending the loop

   • Addresses similar issue of turns ending silently

3. PR fix(opencode): make long-lived provider streams robust to silent SSE terminations #39970 - fix(opencode): make long-lived provider streams robust to silent SSE terminations

   • Handles silent SSE stream terminations

4. PR fix: retry truncated provider streams #39473 - fix: retry truncated provider streams

   • Related to retrying truncated streams

5. PR fix(session): set finish status on halted assistant message #42176 - fix(session): set finish status on halted assistant message

   • Related to finish status handling in session messages

6. PR fix(session): retry empty stream truncations and discard partial parts #26167 - fix(session): retry empty stream truncations and discard partial parts

   • Historical PR addressing empty stream truncations

These PRs appear to tackle the same root problem of empty/unknown finish streams and silent session stops, though this PR (43881) may take a different or more comprehensive approach than its predecessors.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[moritzscheele]

Long-running verification finished, result: green.

Setup: desktop build with this patch, sidecar running from fix/empty-stream-silent-abort, ~3.5 hours of continuous use against the same gateway and model (opencode/x-preview-f-free).

Observations for the test window:

• The gateway stayed flaky: 124 stream error entries logged
• Zero assistant messages were persisted with the previous failure signature (finish unknown/empty, zero output tokens, no error field). Before the patch that signature appeared repeatedly throughout the day
• All affected turns recovered through the retry flow or completed normally; long-running tasks ran to completion without silent stops

One honest caveat: the clean-EOF variant this PR targets did not recur during the window — the observed failures were thrown API errors that the existing retry path already handles. So the guard served as a safety net here; the before/after difference in persisted dead messages is the strongest signal I can offer from live data.

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.