fix: MCP daemon hangs on init when a parse-worker grammar load fails

[arttttt]

Problem

The MCP server can hang on startup / first use and never initialize — on any project, large or small. The shared daemon stops responding and every editor session that connects to it hangs waiting to initialize.

Root cause

ExtractionOrchestrator spins up a parse worker and awaits a grammar-load handshake:

// src/extraction/index.ts (ensureWorker, before)
await new Promise<void>((resolve, reject) => {
  parseWorker!.once('message', (msg) => {
    if (msg.type === 'grammars-loaded') resolve();
    else reject(...);
  });
  parseWorker!.postMessage({ type: 'load-grammars', languages: neededLanguages });
});

The bare once('message') only ever resolves on grammars-loaded. The worker's load-grammars handler had no try/catch, and attachWorkerHandlers' 'error'/'exit' handlers reject only entries in pendingParses (empty during the grammar-load handshake). So if the worker dies while loading grammars (a tree-sitter WASM abort), 'grammars-loaded' never arrives, nothing rejects the promise, and await ensureWorker() hangs forever.

ensureWorker runs inside cg.index() / cg.sync(), which run inside indexMutex.withLock(...). A hung await means withLock's finally release never runs, so the in-process index mutex is held forever. In the shared daemon (#411 — one process across all MCP clients) the background catch-up sync is that hung op, so its gate promise never settles: the first tool call — and every client that connects afterwards — hangs on init, regardless of project size. (The unbounded await predates the daemon — it's from the move to worker-thread parsing — but the shared daemon turned a per-client transient into a permanent, daemon-wide wedge.)

Fix

1. parse-worker.ts — wrap load-grammars in try/catch; report failures as grammars-load-failed instead of dying silently.
2. extraction/index.ts — extract awaitWorkerGrammarLoad() that settles on the first of grammars-loaded / grammars-load-failed / worker error / worker exit / timeout (always cleans up its listeners). On failure the worker is torn down and parsing degrades to in-process (slower but correct) for the rest of the run.
3. mcp/tools.ts (defense in depth) — bound the first-call wait on the catch-up gate (default 120s, override CODEGRAPH_CATCHUP_GATE_TIMEOUT_MS) so a sync that never settles for any reason can't wedge the first call.

Tests

• __tests__/parse-worker-grammar-load.test.ts — awaitWorkerGrammarLoad settles (never hangs) on every outcome and removes its listeners. (The worker path isn't exercised under vitest — parse-worker.js isn't next to the .ts, so useWorker=false — which is why this never surfaced in CI; hence the extracted, directly-testable helper.)
• __tests__/mcp-catchup-gate.test.ts — a gate that never settles no longer hangs the first tool call.

Not included (deliberate follow-up)

A proxy↔daemon JSON-RPC timeout (so a wedged daemon falls back to direct mode) was considered but skipped: the daemon sends hello synchronously and answers initialize without the gate, so after this fix a daemon can no longer go silent on JSON-RPC from any known cause — the timeout would guard a near-impossible case at the cost of reworking the transparent proxy pipe that every session depends on.

🤖 Generated with Claude Code