fix(tests): the control-run test leaves headroom over a slow start

Review finding 703d87e1 (BLOCKER); the timeout and hang live in tests/helpers/timing.mjs as CONTROL_RUN.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen 2026-10-14 18:07:12 +02:00
commit e142556543
Signed by: ktg
SSH key fingerprint: SHA256:JakMjO6FTBBzN0Bhfj9saOoEjaFxlSdYuZQQpM/lF9Q
3 changed files with 51 additions and 5 deletions

View file

@ -23,3 +23,15 @@ export async function fastestWithin(limitMs, measure, tries = 3) {
const fastest = Math.min(...runs);
return { ok: fastest < limitMs, fastest, runs };
}
// The red-proof control-run test (review 630 r9, brief note 3) reads these.
// Red proof gives its three runs one timeout, and the test needs the result and
// start-point runs to finish under it on a loaded machine: the criteria runner
// saw the start point killed at 2 s under full-suite load (review 703d87e1).
// The timeout is raised on purpose and is not a loosened assertion: the test
// checks which run red proof stopped, not how fast a run is. `slowStartMs`
// simulates a slow cold start, above the old 2 s; `hangMs` outlasts the timeout
// by 30 s with a real timer. This is the raise of the test's own threshold
// (2000 -> 15000 ms, 6000 -> 45000 ms) that the floor guard may report as
// loosened-threshold: plan step 1 of round 3 asks for it.
export const CONTROL_RUN = Object.freeze({ timeoutMs: 15_000, hangMs: 45_000, slowStartMs: 2_500 });