Worker ${i} did not report ready after ${attempt + 1} attemp

Error message

Worker ${i} did not report ready after ${attempt + 1} attempt(s); dropping slot.

What it means

Parsing workers must post a ready message after spawn; failing slots are respawned with jittered backoff up to STARTUP_RESTART_BUDGET (2) attempts. This warning fires when a slot exhausts that budget WITHOUT the deterministic-crash-signature detection triggering — the failures looked transient or had no reproducible signature — so the slot is dropped (activeSlots.delete(i)) and the pool continues with the remaining workers.

Source

Thrown at gitnexus/src/core/ingestion/workers/worker-pool.ts:1291

        const msg = err instanceof Error ? err.message : String(err);
        const sig = crashSignature(msg);
        // Same signature as this slot's previous attempt => it survived a
        // respawn, so retrying this slot is futile. (First crash has no prior
        // signature, so attempt 0 never counts — every slot self-heals once.)
        if (lastStartupSignature.get(i) === sig) reproducedStartupSlots.add(i);
        lastStartupSignature.set(i, sig);
        if (!anyWorkerReachedReady && reproducedStartupSlots.size >= deterministicSlotThreshold) {
          deterministicStartupDetected = true;
        }
        await worker.terminate().catch(() => undefined);
        workers[i] = undefined;

        const giveUp =
          terminated || deterministicStartupDetected || attempt >= STARTUP_RESTART_BUDGET;
        if (giveUp) {
          initialReadinessFailures.push(msg);
          activeSlots.delete(i);
          logger.warn(
            { workerIndex: i, attempt, err: msg, deterministic: deterministicStartupDetected },
            deterministicStartupDetected
              ? `Worker ${i} hit a deterministic startup crash-loop; dropping slot without further retries.`
              : `Worker ${i} did not report ready after ${attempt + 1} attempt(s); dropping slot.`,
          );
          return;
        }
        // Transient: jittered backoff, then respawn the slot and retry.
        await abortableSleep(
          startupBackoffMs(attempt),
          () => terminated || deterministicStartupDetected,
          pendingStartupTimers,
        );
        if (terminated || deterministicStartupDetected) {
          initialReadinessFailures.push(msg);
          activeSlots.delete(i);
          return;
        }

View on GitHub (pinned to 0d1aed942f)

Solutions

Check the { err } (msg) and attempt fields in the log for the last failure mode
Reduce load on the machine (fewer parallel jobs) or increase the container CPU share, then re-run
Warm up before indexing: the first run after install builds/loads grammars — a retry often succeeds
Verify memory headroom if msg hints at OOM
If the same signature starts repeating from slot 0 on a fresh run, treat it as the deterministic case (error 398) and rebuild node_modules

Example fix

# before: analyze launched on a saturated CI box; workers miss the readiness window
npx gitnexus analyze  # -> slot dropped after retries

# after: rerun when load drops, confirm slots come up
uptime && npx gitnexus analyze

Defensive patterns

Strategy: retry

Validate before calling

// preflight: spawn one worker and await ready before committing to a full analyze
const probe = pool.acquire();
await withTimeout(probe.ready, 30_000); // if this misses, the box is too loaded - run later

Prevention

Run analyze when the machine is not saturated; low CPU-share containers routinely miss the readiness window
Expect a slower first run after install (grammar source-build) and simply retry once
Ensure memory headroom for grammar loading in each worker
If retries fail with the same signature from the first slot, switch to the deterministic-crash-loop playbook (rebuild node_modules)

When it happens

Trigger: Repeated but non-identical startup failures: a slow/overloaded machine where workers miss the readiness window with varying failure modes, intermittent OOM kills during grammar load (cold cache), CPU starvation in low-share containers, or nondeterministic crashes with different signatures each attempt.

Common situations: CI runners saturated by parallel jobs; first run after install while grammars are source-built (slow startup); containers with low CPU quota where ready messages arrive too late; antivirus scanning each spawned worker.

Related errors

AI-assisted analysis of abhigyanpatwari/GitNexus@0d1aed942f (2026-08-20). Data as JSON: /api/errors/884e71a4d1dc7f42. Report an issue: GitHub.