thedotmack/claude-mem · warning

Live PID detected but worker did not become ready before tim

Error message

Live PID detected but worker did not become ready before timeout

What it means

ensureWorkerStarted() found a live pid in the PID file and waited the readiness window (~30s, platform-adjusted) for /readiness, which reports DB plus search initialization. Readiness never came, but the process is still alive and at least somewhat healthy, so the spawner returns 'warming' — the worker exists, memory is not fully initialized yet.

Source

Thrown at src/services/worker-spawner.ts:104

    return 'dead';
  }

  const pidFileStatus = cleanStalePidFile();
  if (pidFileStatus === 'alive') {
    logger.info('SYSTEM', 'Worker PID file points to a live process, skipping duplicate spawn');
    const ready = await waitForReadiness(port, getPlatformTimeout(HOOK_TIMEOUTS.READINESS_WAIT));
    if (ready) {
      clearWorkerSpawnAttempted();
      logger.info('SYSTEM', 'Worker became ready while waiting on live PID');
      return 'ready';
    }
    const workerStillHealthy = await waitForHealth(port, 1000);
    const workerPidStillAlive = cleanStalePidFile() === 'alive';
    if (!workerStillHealthy && !workerPidStillAlive) {
      logger.error('SYSTEM', 'Live PID disappeared before readiness endpoint became available');
      return 'dead';
    }
    logger.warn('SYSTEM', 'Live PID detected but worker did not become ready before timeout');
    return 'warming';
  }

  if (await waitForHealth(port, 1000)) {
    clearWorkerSpawnAttempted();
    const ready = await waitForReadiness(port, getPlatformTimeout(HOOK_TIMEOUTS.READINESS_WAIT));
    if (!ready) {
      logger.warn('SYSTEM', 'Worker is alive but readiness timed out — proceeding anyway');
    }
    logger.info('SYSTEM', 'Worker already running and healthy');
    return ready ? 'ready' : 'warming';
  }

  const portInUse = await isPortInUse(port);
  if (portInUse) {
    logger.info('SYSTEM', 'Port in use, waiting for worker to become healthy');
    const healthy = await waitForHealth(port, getPlatformTimeout(HOOK_TIMEOUTS.PORT_IN_USE_WAIT));
    if (healthy) {

View on GitHub (pinned to e2d1df569a)

Solutions

1. Wait and re-check — `claude-mem status` or GET /readiness usually turns ready within another minute
2. If it never becomes ready, read worker logs for the init step that stalls (search index build, DB migration)
3. For persistent slowness, reduce the transcript backlog or increase READINESS_WAIT via the platform timeout mechanism

async function waitForWorkerReady(port: number, timeoutMs = 60000): Promise<boolean> {
  const deadline = Date.now() + timeoutMs;
  while (Date.now() < deadline) {
    try { if (await fetch(`http://127.0.0.1:${port}/readiness`).then(r => r.ok)) return true; } catch {}
    await new Promise(r => setTimeout(r, 1000));
  }
  return false;
}

When it happens

Trigger: Large Chroma collection or transcript backlog making DB/search init exceed READINESS_WAIT; cold caches after reboot; first-run dependency setup (uv installing Python deps) stretching startup.

Common situations: Big existing memory databases after an upgrade that runs a migration; under-provisioned machines; concurrent disk-heavy work starving the worker's init.

Understand the failure class

• Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

• Worker is alive but readiness timed out — proceeding anyway
• Worker spawned but readiness endpoint not responding within
• Worker is healthy but not ready; skipping hook API call
• Worker lazy-spawned but did not become ready before hook rea
• Worker is still initializing, please retry

AI-assisted analysis of thedotmack/claude-mem@e2d1df569a (2026-08-20). Data as JSON: /api/errors/08088a7293c48048. Report an issue: GitHub.