parallel-gate-legs-killed-for-memory-count-cannot-see-ram

Parallel Gate Legs Killed for Memory — the Count Cannot See RAM

Problem

Two sessions share one developer machine. Each runs the repo's local test legs before pushing, and each obeys a concurrency rule of the form "at most two heavy legs machine-wide", implemented as a count of running test processes.

Your background leg dies. What you get is not a failure: the log stops, with no traceback, no N passed summary and no exit status, and the harness says the task was stopped because the system was low on memory. The count, sampled throughout, read 1.

Three wrong conclusions are one step away, and all three are natural:

1. "My leg went red." It did not run to a verdict at all.
2. "My loop is broken." The obvious fix — restart it — walks straight back into the same collision, because nothing about the machine changed.
3. "The concurrency rule did not fire, so concurrency was not the problem." The rule cannot see the resource that ran out.

Context / Trigger Conditions

• A run_in_background test leg ends with a low-memory notice, or its output file ends mid-run with no summary
• A process-count check reads 2 for one leg, so any "under 2" threshold is unsatisfiable (the cause is not the obvious one — see Root cause)
• Your rule is phrased "start only if the count is under 2", so it is unsatisfiable while any leg runs anywhere on the machine, yours or a peer's
• memory_pressure's free-percentage headline looks healthy (40%+) while Pages free × page size is tens of megabytes and swap is nearly full
• A peer session is part-way through its own full leg script in another worktree
• The same leg, run alone in the foreground, finishes normally

Root cause

The guard measures the wrong resource. A count of test processes is a CPU and contention rule: it stops two suites fighting for cores and for a shared fixture directory. Memory is not in it at all, so a machine with room for one copy of the heaviest leg will happily admit a second and then kill one of them.