Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:231tqr2lww is past its budget: trevato/forge: "a member and the crew's standing instructions > (unnamed)" failed on 3 pulls in the last hour — the lan… #4470
Check · Review · Land · Live done — Landed and live in production.
This changes `test/member-crew.test.ts` so the "a member and the crew's standing instructions" suite no longer fails when the check machine is slow. The test file passed locally, but I couldn't reproduce the failure, so I haven't confirmed it was the cause.
shipped production is serving it deploy c82665e
This changes test/member-crew.test.ts so the "a member and the crew's standing instructions" suite no longer fails when the check machine is slow. The test file passed locally, but I couldn't reproduce the failure, so I haven't confirmed it was the cause.
The failing entry is "(unnamed)", which points at a beforeAll or afterAll hook rather than a test. The setup is the heavy part: it boots an app and server, then hashes two passwords. It takes about 650 ms here, but it ran against bun's default 5 s hook timeout. Under load that limit is plausibly what failed it.
I gave beforeAll a 60 s timeout and afterAll a 30 s timeout. Those are the values most hooks in test/ already use. No assertions or app code changed.
I left alone the other suites that hash passwords in their setup and might be just as exposed. I ran only this file locally (3 runs, all green), not the full check.
To try it, run bun test test/member-crew.test.ts. Once the sentinel sees green runs, shared:01m23vygyffx5hg2f5vm8r74sr:231tqr2lww should leave the degraded list.
Test-only change: explicit 60 s beforeAll and 30 s afterAll timeouts on the suite that boots an app and hashes two passwords, matching the pattern other hooks in test/ use. No assertions, app code, or security surface touched; no new behaviour needing a test. Within the stability priority (flaky check). Two things I would do next: (1) apply the same hook timeouts to the other suites that hash passwords in setup, ideally through a shared helper so it is not repeated; (2) if the sentinel still flags this suite, look at what slows hashing under load rather than raising the limit again.
This changes
test/member-crew.test.tsso the "a member and the crew's standing instructions" suite no longer fails when the check machine is slow. The test file passed locally, but I couldn't reproduce the failure, so I haven't confirmed it was the cause.The failing entry is "(unnamed)", which points at a
beforeAllorafterAllhook rather than a test. The setup is the heavy part: it boots an app and server, then hashes two passwords. It takes about 650 ms here, but it ran against bun's default 5 s hook timeout. Under load that limit is plausibly what failed it.I gave
beforeAlla 60 s timeout andafterAlla 30 s timeout. Those are the values most hooks intest/already use. No assertions or app code changed.I left alone the other suites that hash passwords in their setup and might be just as exposed. I ran only this file locally (3 runs, all green), not the full check.
To try it, run
bun test test/member-crew.test.ts. Once the sentinel sees green runs,shared:01m23vygyffx5hg2f5vm8r74sr:231tqr2lwwshould leave the degraded list.Closes #4448