fix(daemon): bound MCP proxy hello read so a wedged daemon socket never hangs the handshake#55
Merged
Conversation
…er hangs the handshake A stale or wedged .codegraph/daemon.sock (a crashed daemon that left its socket, or one that accepted the connection but stalled before writing its versioned hello) made the proxy's read_daemon_hello block forever on an un-timed read_line. To an MCP host such as Kiro this surfaced as a 60s "connection timed out" on the initialize handshake. Apply a bounded recv timeout (DAEMON_HELLO_TIMEOUT_MS = 2000) around the hello read and clear it afterwards so steady-state JSON-RPC reads still block normally. On timeout the read returns Err, which spawn_or_proxy already maps to a clean fallback to direct serving.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes an MCP
initializehandshake hang reported by Kiro:MCP server 'codegraph' connection timed out after 60000ms.When a project has a
.codegraph/dir,serve --mcpruns in spawn-or-proxymode: it connects to the shared daemon over a Unix socket and proxies stdio.
The proxy's
read_daemon_hellodid a blockingread_linewith no timeout.A stale or wedged
daemon.sock— a crashed daemon that left its socket behind,or one that accepted the connection but stalled before writing its versioned
hello — made that read block forever, so the host never received an
initializereply and timed out at 60s.Fix
Bound the hello read with a recv timeout (
DAEMON_HELLO_TIMEOUT_MS = 2000)and clear it afterwards so steady-state JSON-RPC reads still block normally.
On timeout the read returns
Err, whichspawn_or_proxyalready maps to aclean fallback to direct serving — the same path that answers
initializein<1s. Uses
interprocess's nativeStream::set_recv_timeout; no new dependency,no stdout bytes, no extraction/golden changes.
Verification
read_daemon_hello_times_out_on_silent_socket:stands up a listener that accepts but never sends a hello and asserts the read
returns
Errnear the 2s bound instead of hanging.daemon.sock(accept-but-never-hello) plus alive-looking pid file;
serve --mcpnow answersinitializein 2.1s(was an indefinite hang) by falling back to direct serving.
make cigreen locally (fmt + clippy + full test suite + guardrail).Note on the second reported issue (skill not in completion)
No code bug. The generated completion script already contains the
skillsubcommand (clap_complete enumerates every subcommand). The complaint is a
stale installed completion file:
skillis not in any released binary yet(latest tag
v0.12.1predates it), andcompletions --installwrites a staticsnapshot. This release ships
skill; after upgrading, re-runcodegraph completions zsh --installto refresh.