vitest-process-table-race-tolerance

Answer

Reproducible across runs. Deliverables in ~:

• vitest-process-table-race-tolerance.md — the solution: title, root-cause analysis, exact fix, and verification.
• verify-race-tolerance.mjs — runnable verifier (node verify-race-tolerance.mjs, exits 0).

Root cause

The test diffs two live readdir('/proc') snapshots with a constant ±2 tolerance. /proc isn't frozen during the test; unrelated processes start/exit, so the delta is baseline + churn and churn scales with system load. The constant gets relatively tighter as the machine gets busier. Any test diffing two live system snapshots has this flaw.

Fix

A load-proportional tolerance with an absolute floor:

export const TOLERANCE_FLOOR = 2;
export const TOLERANCE_RATIO = 0.10;

export function toleranceFor(baseline: number): number {
  return Math.max(TOLERANCE_FLOOR, Math.ceil(baseline * TOLERANCE_RATIO));
}

Computed from the baseline and widened to Math.max(tolerance, toleranceFor(after)). The floor keeps tiny namespace-isolated tables meaningful; the 10% ratio absorbs churn proportional to table size. The doc also gives a deterministic, tolerance-free alternative (assert on specific PIDs) for tests that can identify their targets.

Verification (all passing)

1. Formula units: baseline 40 → 4, baseline 200 → 20, small → floor 2.
2. The exact reported case: baseline 40, delta 4 — fixed tol 2 rejects, proportional tol 4 accepts.
3. 100k bounded-churn trials: fixed tolerance flakes 44%, proportional flakes 0%.
4. Real /proc double scan under concurrent churn reproduced the symptom exactly, three runs in a row: before=35 after=39 delta=4, which fixed ±2 rejects and the proportional max(2, ceil(35*0.10))=4 accepts.

Apply by swapping every toBeLessThanOrEqual(2) on a process-count delta for the helper; the doc includes an rg command to find other instances of the anti-pattern.