Worker silently fails init when 'node' not in PATH, reports status:ok but stays initialized:false forever

[Dee-0503]

Problem

worker-cli restart has a hard-coded 10-second readiness timeout. When the worker cold-starts (loading embedding model, etc.), initialization often takes 10–25 seconds. This causes the CLI to report Failed to restart: Readiness check timed out after 10000ms even though the worker may eventually initialize successfully.

Impact

Combined with health-check or scheduled-restart scripts that rely on the CLI's exit code, this creates a cascading failure loop:

1. Worker loses initialization state (e.g., after macOS sleep/wake)
2. Health check detects initialized=false, calls worker-cli restart
3. CLI times out at 10s → reports failure
4. Worker process is replaced but also can't initialize within 10s
5. Next hourly health check: same result → restart → timeout → repeat
6. Loop persisted for ~20 hours until manual intervention

Evidence from logs

[2026-03-05 15:02:22] ALERT: Worker not initialized after 650min (initialized=false), restarting
Failed to restart: Readiness check timed out after 10000ms
[2026-03-05 16:02:13] ALERT: Worker not initialized after 59min (initialized=false), restarting
Failed to restart: Readiness check timed out after 10000ms
[2026-03-05 19:00:01] ALERT: Worker not initialized after 177min (initialized=false), restarting
Failed to restart: Readiness check timed out after 10000ms
[2026-03-05 20:00:00] ALERT: Worker not initialized after 59min (initialized=false), restarting
Failed to restart: Readiness check timed out after 10000ms

Manual restart at 00:01 succeeded — worker initialized in ~23 seconds.

Suggestion

1. Make the readiness timeout configurable (e.g., worker-cli restart --timeout 30000), defaulting to 30s
2. Or at minimum, increase the default to 30s — 10s is too aggressive for cold starts with embedding model loading
3. Consider making worker-cli restart return success if the worker process was successfully spawned, and add a separate worker-cli wait-ready --timeout <ms> command for scripts that need to verify initialization

Environment

• claude-mem version: 10.0.6
• Platform: macOS (darwin 24.6.0)
• Runtime: bun

— cee

[Dee-0503]

Update: Root cause identified — NOT the readiness timeout

After deeper investigation, the 10s readiness timeout was a symptom, not the cause. The real issue:

Actual root cause

When worker-service.cjs starts in an environment where node is not in $PATH (e.g., spawned via cron/launchd which don't load shell profiles), the background initialization silently fails:

[11:00:03.430] [INFO ] [DB    ] Database initialized
[11:00:03.431] [INFO ] [WORKER] SearchManager initialized and search routes registered
[11:00:03.433] [ERROR] [SYSTEM] Background initialization failed Executable not found in $PATH: "node"

After this error, the worker enters a permanent zombie state:

• Health endpoint returns status: "ok" → misleading
• initialized: false, mcpReady: false → permanently stuck
• All subsequent requests return 503 "Database initialization timeout"
• The worker never recovers on its own — no retry, no exit, no clear signal

This persisted for 20+ hours until manual intervention.

What's on my side (user config)

My cron/launchd restart scripts didn't inject the node manager's PATH (I use fnm). Fixed by adding:

FNM_NODE_DIR="$HOME/.local/share/fnm/aliases/default/bin"
[ -d "$FNM_NODE_DIR" ] && export PATH="$FNM_NODE_DIR:$PATH"

What's on the software side (design improvement suggestions)

1. Silent failure is the main issue. When background init fails due to missing node, the worker should either:
   • Exit with a clear error (so process managers can restart it)
   • Or retry periodically instead of giving up permanently
2. Health endpoint is misleading. status: "ok" when initialized: false is confusing — consider returning status: "degraded" or status: "init_failed" so monitoring tools can distinguish "alive but broken" from "fully functional"
3. The readiness timeout (original issue) is secondary — once node is available, init completes in ~40ms, well within 10s

The original title about timeout was inaccurate. The core request is: please don't silently swallow init failures and report "ok" status when the worker can't function.

— cee

[Shockang]

Confirmed part of this on current main as of 2026-03-08: src/services/worker-service.ts still starts the MCP subprocess with command: 'node', so launchd/cron-style environments with a truncated PATH can still fail even when Node is installed in a standard location.

I opened PR #1301 with a narrow root-cause fix:

• resolve Node via CLAUDE_MEM_NODE_PATH, common install locations, or PATH before launching mcp-server.cjs
• add regression tests for the resolver

One accuracy note for current main: the worker now marks core DB/search initialization complete before attempting the MCP connection, so the exact initialized:false forever symptom described earlier does not appear to match the latest source tree anymore. This PR fixes the remaining hardcoded node lookup problem, but it does not change the health/readiness response contract.

[thedotmack]

Closed during the April 2026 backlog cleanup. This was verified already-fixed in v12.1.1 HEAD. Please update to the latest build. If you still see the issue on current version, open a fresh ticket with repro.