Retry unexpected MessageAbortedError instead of stopping the session

[dzianisv]

Problem

OpenCode can stop a session after a provider-side abort even when the user did not cancel the run.

In the incident we investigated, an assistant message sat for ~16 minutes, produced zero tokens / zero parts, and then completed with:

• MessageAbortedError
• message: \"The operation was aborted.\"

The last tool call had already completed successfully. The next model call never returned any content, then the session stopped instead of retrying.

Actual behavior

When SessionProcessor catches a DOMException / AbortError, MessageV2.fromError() converts it into MessageAbortedError.

SessionRetry.retryable() does not treat that error as retryable, so the processor:

• sets assistantMessage.error
• publishes the error
• returns \"stop\"

This makes the session appear stuck/cancelled even though the user did not explicitly cancel it.

Expected behavior

If the session's own abort signal was not triggered, an unexpected AbortError from the model/provider layer should be treated as transient and retried with the normal retry/backoff flow.

A user-initiated cancel should still stop immediately and remain non-retryable.

Root cause

Current logic treats all AbortErrors as equivalent:

• user cancellation via SessionPrompt.cancel()
• provider/client/network aborts while waiting for streamed output

Those cases need to be separated.

Proposed fix

• detect MessageAbortedError in SessionProcessor
• if input.abort.aborted === false, classify it as retryable and use the existing retry/backoff status flow
• if input.abort.aborted === true, keep the current cancel behavior
• add tests covering both cases

Acceptance criteria

• unexpected AbortErrors retry automatically instead of stopping the session
• explicit session cancellation still stops immediately
• retry status is surfaced through existing SessionStatus retry flow
• tests cover both retryable and non-retryable abort cases

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• No issue template was used. Please use one of the three required templates: Bug Report, Feature Request (title must start with [FEATURE]:), or Question. The content here fits the Bug Report or Feature Request template — please resubmit using the appropriate one.

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

---

This issue might be a duplicate of existing issues. Please check:

• Retry transient local provider connection failures (ECONNREFUSED) in session loop #15851: Retry transient local provider connection failures (ECONNREFUSED) in session loop — same root cause: transient errors treated as non-retryable, causing session to stop instead of retrying
• Provider 520 errors surface as MessageAbortedError with no diagnostics (zero tokens, repeated retries) #9038: Provider 520 errors surface as MessageAbortedError with no diagnostics (zero tokens, repeated retries) — also involves MessageAbortedError from provider-side failures

If you believe this was flagged incorrectly, please let a maintainer know.

[dzianisv]

I opened a fix PR for this: #17719

What it changes:

• retries unexpected MessageAbortedError failures when the session itself was not cancelled
• keeps explicit session cancellation as a terminal stop
• adds regression coverage for both paths
• also fixes a pre-existing branded-ID type issue in packages/opencode/test/session/llm.test.ts so the repo hook/typecheck passes

Validation:

• bun test test/session/retry.test.ts test/session/processor.test.ts
• bun test --timeout 30000
• bun typecheck

[github-actions]

This issue has been automatically closed because it was not updated to meet our contributing guidelines within the 2-hour window.

Feel free to open a new issue that follows our issue templates.