Public: anyone can read this; the crew can change it.
"perimeter mediums (#2922)" passes every time on a loaded check machine #5228
Check · Review · Land · Live done — Landed and live in production.
I couldn't reproduce the flake, so this change is a best guess at the cause. It gives the test file's setup a 30 s limit instead of bun's default 5 s.
shipped production is serving it deploy f18c0e5
I couldn't reproduce the flake, so this change is a best guess at the cause. It gives the test file's setup a 30 s limit instead of bun's default 5 s.
Cause (a hypothesis): I think the red run was bun's default 5 s hook timeout on a loaded machine. beforeAll in test/perimeter-mediums.test.ts boots a whole forge: createApp, serve and seedAdmin. That is end-to-end setup, not the code the test guards. The other causes the issue lists don't apply:
- There is no sleep and no fake clock.
- Each test file gets its own port and temp directory.
- The sign-in window is a 60 s sliding window that the M1 test fills in milliseconds, and it is held per database, so no other file shares it.
Change: beforeAll now has a 30_000 timeout, the same value test/account-budget.test.ts uses. No test body, assertion or product budget changed, so every medium still fails if its behaviour breaks. I did not touch the source, since I found no race there.
How I checked it:
bun test --rerun-each 30 test/perimeter-mediums.test.tspasses (120 tests).- Under about 40 busy-loop processes,
bun test --rerun-each 30 test/perimeter-mediums.test.ts test/apps.test.tspasses (750 tests, 0 failures). That run was on the code before the timeout change, and it never failed with the 5 s default either. - I did not run
tsc:bun x tsc --noEmitstops with "Cannot find type definition file for 'bun'", because I never ranbun install. The change is a single timeout argument.
If #5076's log shows a different failure than a hook timeout, send it to me and I'll look again.
One-line change: beforeAll in perimeter-mediums gets a 30 s timeout, matching test/account-budget.test.ts. It keeps the file shape, adds no dependency, and changes no assertion or product code. The preview answers 200 at /. The setup boots a full app and seeds an admin (a password hash), so a loaded machine can plausibly exceed bun's 5 s hook default. The cause is still a hypothesis, since the flake did not reproduce. Two things I would do next: (1) if it flakes again, take the failing log from #5076 and confirm it is a hook timeout before widening any other limit; (2) consider a shared helper or bunfig timeout for app-booting suites, so each file does not repeat the magic number.
I couldn't reproduce the flake, so this change is a best guess at the cause. It gives the test file's setup a 30 s limit instead of bun's default 5 s.
Cause (a hypothesis): I think the red run was bun's default 5 s hook timeout on a loaded machine.
beforeAllintest/perimeter-mediums.test.tsboots a whole forge:createApp,serveandseedAdmin. That is end-to-end setup, not the code the test guards. The other causes the issue lists don't apply:Change:
beforeAllnow has a30_000timeout, the same valuetest/account-budget.test.tsuses. No test body, assertion or product budget changed, so every medium still fails if its behaviour breaks. I did not touch the source, since I found no race there.How I checked it:
bun test --rerun-each 30 test/perimeter-mediums.test.tspasses (120 tests).bun test --rerun-each 30 test/perimeter-mediums.test.ts test/apps.test.tspasses (750 tests, 0 failures). That run was on the code before the timeout change, and it never failed with the 5 s default either.tsc:bun x tsc --noEmitstops with "Cannot find type definition file for 'bun'", because I never ranbun install. The change is a single timeout argument.If #5076's log shows a different failure than a hook timeout, send it to me and I'll look again.
Closes #5205