Sessions fail on transient network errors instead of retrying

[literally-dan]

Description

The session retry path only treats ECONNRESET as retryable. Other transient transport failures are classified as hard errors, so a brief network problem kills the assistant turn instead of being retried by the existing retry policy.

Cases that currently fail the session outright include system error codes such as ETIMEDOUT, ENOTFOUND, EAI_AGAIN, ECONNREFUSED, EHOSTUNREACH, ENETUNREACH, and EPIPE; request timeouts surfaced as a TimeoutError; and bare fetch/undici errors whose only signal is the message text, such as fetch failed, socket hang up, terminated, and other side closed.

On a flaky connection this shows up as the turn ending with an error that a retry would have recovered from.

This is a different layer from #21893 (provider/stream-layer stream_read_error and wrapped rate-limit errors) and from #20822 (a broader "retry UnknownError by default" strategy). This issue is specifically about transport/socket-level failures in MessageV2.fromError.

I have a fix that widens the retryable classification while keeping a real user cancel non-retryable.

Plugins

None

OpenCode version

1.15.13

Steps to reproduce

1. Start an assistant turn that makes a provider request.
2. Trigger a transient transport failure (drop the network briefly, or force a DNS failure / connection timeout) so the error surfaces as one of the system codes above, a TimeoutError, or a bare fetch failed / socket hang up.
3. The session ends in error instead of entering retry, even though the existing retry policy would have recovered.

Screenshot and/or share link

No response

Operating System

Linux 6.17.0-29-generic

Terminal

foot

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• Missing required bug report template fields: OpenCode version, Operating System, Terminal, and Steps to Reproduce. Please use the full bug report template and include these details so maintainers can reproduce and triage the issue.

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:

• Some transient stream/rate-limit errors bypass retry and terminate sessions #21893: Same root cause — transient stream/rate-limit errors bypass the session retry path and terminate sessions instead of retrying
• fix(session): UnknownError should be retried by default #20822: UnknownError (which covers unexpected network failures) is never retried, causing sessions to die on transient errors

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

[literally-dan]

Closing this, I opened it before it was ready for review. I'll reopen once I've gone over it properly.

[github-actions]

Thanks for updating the issue! Everything looks good now — the description is clear, steps to reproduce are included, and system info is provided. The needs:compliance label has been removed.