OpenCode keeps attempting connection to unreachable provider without giving a connection error #40319

Activity

1. github-actions

   assigned

   rekram1-node

   on Aug 3, 2026
2. github-actions commented on Aug 3, 2026

   

   github-actionsBot

   on Aug 3, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • OpenCode repeatedly retries after a mid-tool provider disconnect #32286: OpenCode repeatedly retries after a mid-tool provider disconnect — same core behavior of unbounded retries with no visible error surfaced
   • [FEATURE]: Fast failure on network errors and concise error output #39771: [FEATURE]: Fast failure on network errors and concise error output — related request for fast failure when a provider is unreachable
3. Martossien commented on Aug 3, 2026

   

   Martossien

   on Aug 3, 2026

   More actions

   We hit the exact same behavior (filed #40330 before spotting this one — closing ours as duplicate). Since we had traced it through the v1.18.11 source before filing, here is the root-cause analysis in case it helps:

   1. @ai-sdk/provider-utils's handleFetchError marks every network-level failure — including ECONNREFUSED — as APICallError { isRetryable: true }.
   2. opencode propagates the flag untouched: packages/opencode/src/session/message-v2.ts:676-704 and packages/opencode/src/provider/error.ts:181. There is no branch for ECONNREFUSED/ENOTFOUND/EHOSTUNREACH (contrast with the explicit ECONNRESET handling at message-v2.ts:625-637).
   3. The retry policy never gives up: packages/opencode/src/session/retry.ts:68-79 always returns an object while isRetryable is true, and retry.ts:176-200 builds a Schedule with no Schedule.recurs and no time budget — only the delay is capped (RETRY_MAX_DELAY_NO_HEADERS = 30_000, retry.ts:26-28). Net effect: one attempt every 30 s, forever.
   4. packages/opencode/src/session/processor.ts:660-675 applies Effect.retry(...) before Effect.catch(halt), so halt is unreachable — no session.error, never idle.
   5. Non-interactive mode compounds it: packages/opencode/src/cli/cmd/run.ts:789-793 only exits on idle, and the retry status events (emitted at processor.ts:664-672) are consumed by the TUI but nowhere in run.ts — not even with --format json. So opencode run shows literally nothing while it loops.
   6. No configuration escape: timeout/headerTimeout/chunkTimeout (provider.ts:1737-1768) only arm on an established connection, and headerTimeout gets a default only for the openai provider (provider.ts:208).

   Reproduced on 1.17.4, 1.17.13, 1.17.14 and 1.18.11 with a minimal isolated config (fresh XDG_CONFIG_HOME/XDG_DATA_HOME, one custom provider, no plugins). A live-but-slow endpoint is fine; the trigger is strictly connection refused. A 30-second no-GPU repro script is in #40330.

   Suggested fixes (any subset helps): treat ECONNREFUSED/ENOTFOUND/EHOSTUNREACH as non-retryable (or bounded), add a max-attempts/time budget to the schedule, surface the retry status in run mode, and/or expose --max-retries/--timeout on opencode run. Note #39790 traces to the same unbounded SessionRetry.policy() via 429s.

   👍React with 👍1Reacted by Grant Williams
4. grantwilliams-ai commented on Aug 3, 2026

   

   grantwilliams-ai

   on Aug 3, 2026

   Author

   More actions

   Thanks for tracing this so clearly and consolidating #40330 here. This explains exactly what we were seeing, especially why opencode run stays silent without returning to idle. The cross-version reproduction and no-GPU script should make this much easier to act on. Much appreciated.
5. github-actions commented on Oct 4, 2026

   

   github-actionsBot

   on Oct 4, 2026 – with GitHub Actions

   Contributor

   More actions

   To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
6. github-actions

   closed this as not plannedon Oct 4, 2026