test(parse-pool): wait for the idle fault to land, not for 120ms

[josephismikhail]

What

takes a worker that faults while IDLE out of the free list is load-flaky. It failed a full-suite run on a busy machine with b2.ts returning null — indistinguishable from the Ix#567 bug it guards, which is the worst way for a flake to present: whoever sees it red next has no reason to suspect the harness.

Reproduction

The fixture throws 20ms after serving the first task; the test slept a flat 120ms waiting for the 'error' event before dispatching two parses.

condition	result
idle	0 of 10 runs failed
saturating CPU load	1 of 8 runs failed

Under load the event had not been delivered, so the second parse reached an already-dying worker and resolved null.

Fix

Wait on the condition, not a duration. onError increments respawns and pushes the replacement in the same synchronous handler, so a non-zero count means the pool has finished reacting — including to a fault with no task in flight, which crashedTasks() deliberately does not count because no file was lost.

That distinction is precisely why there was nothing to wait on, and why this adds respawnCount() rather than reusing a counter. It earns its place outside the test as well: a run that quietly respawned a dozen workers looks identical to a healthy one in every other counter the pool exposes.

What I am not claiming

Post-fix loaded runs were 0 of 8. That is not strong evidence — under the observed 1-in-8 rate, zero in eight happens 34% of the time. The argument is structural: the test no longer depends on an event arriving inside a fixed window, so the failure mode is removed rather than made less likely. It also returns as soon as the condition holds, so it is faster than the sleep it replaces.

The test still catches the bug

With the idle.splice in onError deleted — Ix#567 restored — the test fails, hanging until the 20s timeout, which is the "promise never settles" symptom exactly. The poll signal increments after that splice, so it does not depend on the fix being present and cannot mask its absence.

The other five fixed sleeps in this file wait for a parse to be dispatched rather than for an error to be delivered, and none has been observed to fail. Left alone rather than rewritten on speculation.

Verification

• 13 pool tests pass; full suite 1791 (3 known Windows symlink failures, unrelated, pass on CI's windows-2022)
• typecheck and lint clean
• mutation-tested as above

🤖 Generated with Claude Code

https://claude.ai/code/session_01B5bkc5oUL4SapwDE13UgHt

[josephismikhail]

Now reproduced on CI, not just locally

Test (windows-2022 · node 22) on PR #649 (4d8046b) failed with exactly this:

AssertionError: expected [ { filePath: 'a2.ts' }, null ] to deeply equal [ { filePath: 'a2.ts' }, …(1) ]
-   { "filePath": "b2.ts" },
+   null,
 ❯ src/cli/__tests__/parse-pool.test.ts:137:18

run 34179642182 — same test, same assertion, same line.

#649 does not touch parse-pool.test.ts. Its diff is ingest-files.test.ts, ingestion-loader.test.ts, ingestion-loader.ts. So this is not that PR's regression — it is this flake, and the windows-2022 runner is loaded enough to hit it.

That upgrades the evidence here in two ways:

1. The failure mode is real on CI, not an artifact of my synthetic load. A green history simply means the runner usually delivers the 'error' inside 120ms.
2. It manifests as b2.ts → null, which is the Ix#567 signature. Anyone triaging that red on an unrelated PR would start by suspecting their own change, which is the cost this fix removes.

Merging this first would clear #649's red without touching #649.