The check job's race passes are set by their total work: the macOS pass keeps a steady 2.80 to 2.85 of its runner's three test slots busy and the ubuntu one about 3.4 of four, so no reordering shortens them, and their slowest packages (internal/core/implement/loop, internal/surface/cli, internal/core/claim, about 46% of the macOS pass) spend most of it in git processes. A first cut, a default-branch name per claim operation and a batched view (#1099, #1100), took one drain test from 1,107 git processes to 830 but the whole of the loop and claim packages only from 126,334 to 119,327 (5.5%), which CI could not tell from the difference between runners; a cut measured on one test overstates the package.

The check job's race passes are set by their total work: the macOS pass keeps a steady 2.80 to 2.85 of its runner's three test slots busy and the ubuntu one about 3.4 of four, so no reordering shortens them, and their slowest packages (internal/core/implement/loop, internal/surface/cli, internal/core/claim, about 46% of the macOS pass) spend most of it in git processes. A first cut, a default-branch name per claim operation and a batched view (#1099, #1100), took one drain test from 1,107 git processes to 830 but the whole of the loop and claim packages only from 126,334 to 119,327 (5.5%), which CI could not tell from the difference between runners; a cut measured on one test overstates the package.

On 2026-11-01 the macOS pass ran into the job's cap in a merge group and dropped two pull requests (#1326, #1322) with no test failing. The watchdog stopped it at its 1h20m deadline (the 85-minute cap less its 5-minute margin), run 41317526495. In that run internal/surface/cli took 1203s, internal/core/implement/loop 1511s and internal/adapter/scanner 1133s under the race detector, and internal/core/memory, internal/core/release and internal/core/repolint were still running when it was stopped. Since the pass already keeps its three slots busy, splitting it across separate jobs is the only change that shortens one job, besides cutting the work this record measures. #1326 merged after one re-arm. #1322 was re-queued too, then left the queue again over an unrelated conflict with main.

2026-11-03: in #1347's merge-group run 41534357202 the macOS race job reached the ci-watchdog's 1h20m deadline, which sent SIGQUIT to three test processes, and a timing-bound test failed under the load. #1347, a records-only change, left the queue four times that night (a cancelled job, then three timing failures), each attempt costing about 80 minutes.

2026-11-03: after #1372's speed cuts merged (11:34), #1355's merge-group macOS job still reached the ci-watchdog's 1h20m deadline (run 41664455317, started 15:37) and left the queue; #1364 and #1370 had done the same earlier that day. The race pass is still at the cap: more work must come out of the slowest packages (internal/core/implement/loop, internal/surface/cli), or the macOS pass split across jobs, a ruleset change for the person.

2026-11-03, measured across merge-group runs with the same work and the same restored cache: run 41735871600 took 34 minutes (concurrency 4.7, implement/loop 1132s), runs 41706118055 and 41693198677 reached the 1h20m deadline (concurrency 2.8, implement/loop 2232s and 1891s). Hosted macOS runners vary about 2x, so the cap cannot be met reliably by cutting tests alone. The queue's check_response_timeout_minutes of 90 sets the cap.