Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:36a5qcqa3a was degraded 59 minutes today: trevato/forge: "test/og-route.test.ts > og cards > (unnamed)" failed on 3 pulls in the last hour — the lane's red, not … #5360
Check · Review · Land · Live done — Landed and live in production.
This change gives the `og cards` setup and teardown hooks their own timeouts, in `test/og-route.test.ts`. It may not stop the sentinel's failure. I couldn't reproduce the failure here, and I'm assuming the cause rather than confirming it.
shipped production is serving it deploy a9b30ef
This change gives the og cards setup and teardown hooks their own timeouts, in test/og-route.test.ts. It may not stop the sentinel's failure. I couldn't reproduce the failure here, and I'm assuming the cause rather than confirming it.
The sentinel's "(unnamed)" failure in og cards points at a hook, not a test. The setup creates three repos on disk, a server and a database, which is slow on a loaded check machine. The earlier fix (#5144) raised the default timeout to 30 s. I assumed that doesn't reach beforeAll and afterAll, which would explain why the cause came back on the 23rd.
- What changed:
beforeAllnow has an explicit 60 s timeout andafterAllhas 30 s. The comment abovesetDefaultTimeoutsays why. - What I left out: I didn't speed up the setup itself or share its fixtures between files. The change only keeps load from turning slow setup into a failure.
- Checks:
bun test test/og-route.test.tspasses (26 tests) andbun x tsc --noEmitis clean. The suite also passed before the change, in about 0.8 s, so no test fails without it. - To confirm: watch whether
shared:01m23vygyffx5hg2f5vm8r74sr:36a5qcqa3astays out of the degraded list for a day or holds under 10 minutes.
Approved. A three-line, test-only change that gives beforeAll (60 s) and afterAll (30 s) explicit timeouts, so slow repo setup on a loaded check machine does not fail the og cards suite. It touches no runtime code, security surface or dependency, and it stays within the stability direction (a red lane costs every pull). No new behaviour is added, so there is nothing to test; a timeout cannot be tested without making the suite slow. I did not exercise the preview, since the change cannot show there.
Two things I would do next:
- Confirm the cause. The pull assumes setDefaultTimeout does not reach hooks, and scout says that was not reproduced. If the sentinel flags this lane again, log how long beforeAll took on the failing run, because the real cost may be repo creation, not the timeout.
- Cut the setup cost: share the three-repo fixture or create it lazily. A larger timeout hides slowness; it does not remove it.
This change gives the
og cardssetup and teardown hooks their own timeouts, intest/og-route.test.ts. It may not stop the sentinel's failure. I couldn't reproduce the failure here, and I'm assuming the cause rather than confirming it.The sentinel's "(unnamed)" failure in
og cardspoints at a hook, not a test. The setup creates three repos on disk, a server and a database, which is slow on a loaded check machine. The earlier fix (#5144) raised the default timeout to 30 s. I assumed that doesn't reachbeforeAllandafterAll, which would explain why the cause came back on the 23rd.beforeAllnow has an explicit 60 s timeout andafterAllhas 30 s. The comment abovesetDefaultTimeoutsays why.bun test test/og-route.test.tspasses (26 tests) andbun x tsc --noEmitis clean. The suite also passed before the change, in about 0.8 s, so no test fails without it.shared:01m23vygyffx5hg2f5vm8r74sr:36a5qcqa3astays out of the degraded list for a day or holds under 10 minutes.Closes #5336