fix(lsp-daemon): retry mid-request socket close/error instead of bailing out - #6256

Summary

When the shared LSP daemon closes or errors on the socket after a request has been written, the client reports requestWritten=true, which the retry loop in callToolViaDaemon treats as terminal:

if (error instanceof DaemonRequestError && (error.requestWritten || !isRetryableTool(name))) break;

In production this is almost always wrong. The daemon only closes a connected socket mid-request when one of the following happens:

• the per-language-server idle timeout fires (lsp-core/src/lsp/manager.ts, 5 min default) and the backing LSP process — and therefore the in-flight request — is torn down,
• the daemon itself is killed (parent proxy exit, OOM, crash, manual restart),
• the host loses the unix socket.

In every one of those cases the request never produced a result, but the client still surfaces LSP daemon unreachable: daemon connection closed and never tries again — even though ensureDaemonRunning would respawn the daemon on the next attempt. End-user impact is a recurring MCP connection closed server=lsp WARN in opencode that resolves only after the next, unrelated tool call lazy-spawns a fresh daemon.

Changes

• packages/lsp-daemon/src/daemon-client.ts: the close and error socket handlers now reject with requestWritten=false. This lets the existing 3-attempt retry loop re-ensure the daemon and resend. Timeouts still reject with the live requestWritten value, since the daemon may still be processing the original request when the timer fires.
• Mutating tools remain single-shot: isRetryableTool(name) already gates rename/lsp_rename, so this change does not introduce duplicate-rename risk.
• packages/lsp-daemon/test/daemon-client-retry.test.ts: the prior #given the server closes the connection after reading the request #then no retry happens test encoded the old terminal-on-close behavior, so it is split:
  • #given the server closes the connection after reading the request #when the next ensure reopens the daemon #then the second attempt succeeds — first server closes mid-request, the second ensure swaps in a stable server, and the second attempt returns "ok".
  • #given every attempt closes the connection after reading the request #when all three retries close #then the call is reported as a daemon connection failure — three close-in-a-row attempts still surface daemon connection closed and now assert requestCount === 3 (was 1).

QA & Evidence

• RED before the source change: the new reopen-on-close test failed with expected "ok" — received: "LSP daemon unreachable: daemon connection closed", and the all-three-close test failed with expected requestCount 3, received 1.
• GREEN after the source change:
  • packages/lsp-daemon/test/daemon-client-retry.test.ts: 11 pass / 0 fail (was 10 pass / 0 fail before this PR).
  • packages/lsp-daemon full suite: 114 pass. The 8 pre-existing failures are unrelated vitest-v4 / bun-runner environment issues (vi.mocked, vi.advanceTimersByTimeAsync, ./package.json resolution under bun), all of which fail identically on upstream/dev without this change.
• npx tsc --noEmit (project packages/lsp-daemon): clean.
• biome check src/daemon-client.ts test/daemon-client-retry.test.ts: clean.

Risks & Residuals

• A mid-request close with a side-effecting-but-not-rename tool (e.g. a future code-action apply) could now run twice on retry. Today the only mutating tool routed through the daemon is rename, which isRetryableTool() already excludes, so this risk is theoretical for the current toolset and is the same shape of risk the existing retry-after-auth-refresh path already accepts.
• This is a client-side resilience fix; it does not change daemon-side idle-shutdown behavior or address the underlying MCP connection closed WARN surfacing in opencode (a separate transport-reconnect concern tracked locally; an upstream opencode issue will be filed for that side).

Related

• Builds on the error taxonomy introduced in fix(lsp-daemon): report cancelled and timed-out requests accurately #6250 and the cancellation lifecycle from fix(lsp): cancel daemon calls when proxy parent closes #6117. The retry/cancel/timeout control flow is otherwise unchanged.
• No upstream issue exists for this specific requestWritten-on-close gap; gh issue list --search "requestWritten connection close retry" returned no matches.

Summary by cubic

Retries LSP daemon calls when the socket closes or errors mid-request, but only for idempotent read-only tools; previously any close/error after the request was written surfaced immediately as "daemon connection closed" even though the daemon would respawn on the next attempt.

• close/error handlers in daemon-client.ts now report requestWritten=false only for idempotent tools; timeouts still report the live value.
• Adds retryable-tools.ts with an explicit allowlist of idempotent tools (status, diagnostics, goto_definition, find_references, symbols, prepare_rename), replacing the old rename-only deny list.
• Non-idempotent tools (rename, install_decision, format) keep at-most-once semantics and are never retried after a close.

^{Written for commit ff671c8. Summary will update on new commits.}