Repository navigation
test(ci): hold the runner's clock in the remaining ci-runner waiting tests - #3158
Conversation
…imeout tests Five ci-runner tests raced real time against the runner's per-file timeout, lane deadline or cleanup allowance and failed every time on 2 CPUs under stress -c 256: the timed-out process group, the timed-out file's diagnostics, the hung preparation at the lane deadline, the hung cleanup's commands, and (through its own 30 s spawnSync guard) the cancelled job's cleanup. Each fixture now creates a gate file once it reaches the state under test, and the runner's clock (tests/helpers/ci-runner-held-clock.mjs) holds until then. The hook-timeout test moves too and drops its timeout from 8 s to 3 s.
…ner tests Review nit: holding from the start makes each limit run exactly its length after the gate (comments said five, three and two seconds, but a hold one second in gave up to a second less), and pins the hung preparation's limit to the whole 3 s left before the deadline.
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
Codex review: needs maintainer review before merge. What this changesThis PR holds the runner clock until five fixtures are ready and increases the cancelled-job test’s outer timeout. Example: A busy host takes more than 5 seconds to reach the hung preparation.
Review scores
ProductKind: Test only · Worth it: Yes · Fix scope: Complete Merge readiness✅ Ready for maintainer review Keep open: this maintainer-authored PR addresses concrete test timing races, preserves the runner assertions, and introduces no identified correctness defect. Priority: P2 Before mergeNone. FindingsNone. Tests
Agent review detailsHow this fits togetherThe CI runner integration suite launches the real runner against temporary fixture manifests and checks its result files, diagnostics, and surviving processes. flowchart LR
A[Integration test] --> B[Runner subprocess]
C[Held clock preload] --> B
B --> D[Fixture preparation and tests]
D --> E[Readiness gate files]
E --> C
B --> F[Diagnostics and process cleanup assertions]
Technical reviewBest possible solution: Reuse the existing held clock at fixture readiness boundaries while retaining real runner timeout, diagnostics, and process cleanup assertions. Do we have a high-confidence way to reproduce the issue? Source confirms that fixture startup competes with absolute deadlines and timeout allowances; the author reports repeated failures under two-CPU contention, but this review did not execute tests. Is this the best way to solve the issue? The change targets fixture readiness through the established clock helper and retains meaningful assertions against the real runner rather than replacing its behavior. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 8316ff9031a7. Provenance checked
TestingProof path: in-process harness. SecurityNone. EvidenceWhat I checked:
Likely related people:
Review metrics
LabelsLabel changes:
Label justifications:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior. WorkflowClawSweeper edits this one comment on every review. Comment Reviewed October 21, 2026, 8:46 PM ET / October 22, 2026, 00:46 UTC. |
Problem
#3149 moved two lane-deadline tests in
tests/integration/ci-runner.test.mjsonto a held runner clock (tests/helpers/ci-runner-held-clock.mjs, finding 2164). Other tests in the file still race real time against a runner limit, and fail on main when the host is very busy. On 2 CPUs (taskset -c) withstress -c 256on the same CPUs, 10 runs of the waiting block plus the cancelled-job test on main:lane-deadlineinstead ofprepare-timeout)spawnSyncguard vs. both files runningpassesfinishingThe other waiting tests ("timeout before any test started", "under a second left", and the two #3149 moved) passed 10/10; the rest of the file passed one full loaded run (842 s).
Change
Test-only;
scripts/ci/run-tests.mjsis unchanged.afterhook starts, when the hung preparation starts, and once the cleanup's command and its descendant are on record (now written with one rename, so the gate and the cleanup see both pids at once). Each limit then runs its full length after the gate.elapsedMsupper bound counts from when the fixture printed its last line, because the runner records real time and the clock stood still until then. Its 30 s wait is still far past the bound.passesfinished.spawnSyncguard goes from 30 s to 120 s. It only stops a hang; a guard SIGTERM still fails theSIGKILLassertion.Verification
stress -c 256, 10 runs: see the table.Risks