Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:6eqienm8vy is past its budget: trevato/forge: "no tight wall-clock bound in a test > no test file bounds a request or a spawn below the floor" failed … #3489
Check · Review · Land · Live done — Landed and live in production.
The sentinel test "no test file bounds a request or a spawn below the floor" no longer fails when the check machine is slow. I couldn't reproduce the red here, so the cause is inferred. In this sandbox the test passes in about 0.3 s, and `test/flake.test.ts` passes in full (26 tests).
shipped production is serving it deploy 7cfd21c
The sentinel test "no test file bounds a request or a spawn below the floor" no longer fails when the check machine is slow. I couldn't reproduce the red here, so the cause is inferred. In this sandbox the test passes in about 0.3 s, and test/flake.test.ts passes in full (26 tests).
Cause: the test reads and scans all ~700 files in test/ and had no timeout, so it ran under bun's 5 s default. On a loaded check machine, the file reads alone can plausibly exceed that. Its verdict then depended on the machine rather than on the code under test.
Change: I gave that test a 120 s timeout in test/flake.test.ts, which is the same figure the neighbouring admit test already uses. I did the same for "nothing the gate runs, or runs it, retries", which reads every gate file the same way and could fail the same way.
Left alone: the detector (tightBounds) and the 200 ms floor.
Check: the forge's check will show whether it holds under real load. The sentinel cause should clear once main goes green.
Two-line change in test/flake.test.ts: the two whole-tree scanning tests get a 120 s timeout, the same figure and comment style as the neighbouring admit test (line 270). It leaves the detector and the 200 ms floor alone, adds no dependency, and touches nothing on the page, so there is no security or terminal surface to check. The cause is inferred rather than reproduced, which the description says plainly. Next: (1) if the red returns on the check machine, find out why a read of about 700 files takes over 5 s, because the timeout would then be hiding a slow disk or a load problem. (2) Read the files once in a shared helper instead of in each scan test, so a slow machine pays for the reads once.
The sentinel test "no test file bounds a request or a spawn below the floor" no longer fails when the check machine is slow. I couldn't reproduce the red here, so the cause is inferred. In this sandbox the test passes in about 0.3 s, and
test/flake.test.tspasses in full (26 tests).Cause: the test reads and scans all ~700 files in
test/and had no timeout, so it ran under bun's 5 s default. On a loaded check machine, the file reads alone can plausibly exceed that. Its verdict then depended on the machine rather than on the code under test.Change: I gave that test a 120 s timeout in
test/flake.test.ts, which is the same figure the neighbouringadmittest already uses. I did the same for "nothing the gate runs, or runs it, retries", which reads every gate file the same way and could fail the same way.Left alone: the detector (
tightBounds) and the 200 ms floor.Check: the forge's check will show whether it holds under real load. The sentinel cause should clear once main goes green.
Closes #3419