mcp: remote server latched as failed after one transient DNS error (no retry/backoff) #62369

Summary

A remote HTTP MCP server that fails to connect once with a transient DNS error (getaddrinfo ENOTFOUND) stays latched as failed for the rest of the day — no retry with fresh DNS ever runs. The trigger is routine: the MCP reconnect that fires right after wake-from-sleep lands in the ~30–60s post-resume DNS gap. Recovery requires a manual per-server reconnect or a service restart (which kills running sessions).

Environment

• opencode version: 2.2.5 (first observed on 2.2.0; behavior unchanged across the upgrade)
• OS: Linux 7.2.11-200.fc44.x86_64 (Fedora 44, linux x64)
• Terminal: kitty (TERM=xterm-kitty, COLORTERM=truecolor)
• Shell: /bin/bash
• Install/channel: latest (release)
• Active plugins: none found in config (one npm-global history plugin auto-installed from config plugin array; no .opencode/plugin/ files)

Reproduction

Intermittent by nature (it is a timing race), but reproduced on 3 of 4 consecutive workday mornings:

1. Configure a remote HTTP MCP server in mcp.servers ("type": "remote", "url": "https://<your-erp-host>/api/method/.../handle_mcp", OAuth) and let the shared background service (opencode serve --service) own the connection.
2. Suspend the machine overnight.
3. Wake it. systemd-resolved flushes its cache on resume (Clock change detected. Flushing caches.) and Wi-Fi takes ~30–60s to re-associate.
4. ~30s after wake, OpenCode fires an MCP reconnect cycle. If the network is not back yet, getaddrinfo returns ENOTFOUND instantly and the server is marked failed.
5. Observe that opencode mcp list still reports failed: getaddrinfo ENOTFOUND <your-erp-host> hours later — while the same hostname resolves fine from any shell (getent hosts <your-erp-host>) and the endpoint answers curl immediately.

Morning-by-morning log evidence (wake times from journalctl, reconnect from the server log):

Expected Behavior

A failed connect with a transient error (DNS resolution failure, connection refused, etc.) is retried with backoff until the network returns, and the server self-heals to connected — as implemented by the referenced PR below.

Actual Behavior

The failure latches permanently. The server log shows the connect attempt failing in 2ms — no network attempt at all, an instant negative resolver answer:

level=WARN message="mcp http request failed" errors="[{"type":"TypeError","message":"getaddrinfo ENOTFOUND <your-erp-host>","code":"ENOTFOUND","errno":4}]" durationMs=2
level=WARN message="mcp transport error" server=<server> error="getaddrinfo ENOTFOUND <your-erp-host>"
level=WARN message="mcp connect failed" server=<server> status.status=failed status.error="getaddrinfo ENOTFOUND <your-erp-host>"

and nothing further for that server until a manual reconnect: opencode mcp list at 07:52 and again at 14:43 shows the identical failure, with DNS healthy the entire time.

Additional Context

• The durationMs=2 is the diagnostic key: the failure is a cached negative lookup inside the service, not a real network attempt. Shell-side resolution succeeding while the service still reports ENOTFOUND confirms the latch is internal.
• Known fix exists but is unmerged: PR #52943 "fix(mcp): reconnect dropped servers with backoff" implements exactly this (exponential-backoff retry on failed initial connect and on onclose, with clean stop conditions for auth-required states). It was closed unmerged on 2026-10-10. Its description matches this bug: "the server is marked failed and stays dead until the app restarts or the user manually reconnects... There is no recovery path."
• Same fragility family, other triggers: mcp: opencode_console 403 - console refused access to the workspace, silent reconnect every ~6s #59806 (retry loop on a permanent 403 — the inverse: retries forever when it should stop), mcp: expired OAuth bearer on reconnect hits 429 instead of 401, so refresh never runs #60269 (expired bearer + 429 → no refresh, latched for hours). Common root: MCP connect failure states with no recovery/backoff policy.
• Workaround (non-disruptive, verified): re-resolve and reconnect a single server without touching running sessions:
  opencode api post '/api/experimental/mcp/<server>/connect?location[directory]=<workspace>'
  (/mcps → reconnect in a TUI also works; opencode service restart works but interrupts all sessions).
• Frequency: every workday morning when the race is lost (3 of 4 consecutive days observed).