Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:3fvet6f1u6 is past its budget: trevato/forge: "/map after a write > (unnamed)" failed on 3 pulls in the last hour — the lane's red, not theirs; they w… #3063
Check · Review · Land · Live done — Landed and live in production.
This pull changes the `/map after a write` suite's `afterAll` teardown hooks in `test/map-cache.test.ts` to get a 60 s timeout. That is my best guess at the cause, and I couldn't reproduce the failure.
shipped production is serving it deploy fb6f20c
This pull changes the /map after a write suite's afterAll teardown hooks in test/map-cache.test.ts to get a 60 s timeout. That is my best guess at the cause, and I couldn't reproduce the failure.
Cause. The failure was reported as "(unnamed)", which points to a setup or teardown hook rather than one of the three tests. The setup hooks already had 60–120 s timeouts. The two teardown hooks had none, so bun's 5 s default applied. They stop the server, close the apps and delete the temp directories, and that can overrun 5 s on a loaded check machine. I did not confirm that this is what failed in the three red pulls.
Change. Both teardown hooks now have the same 60 s timeout. No test logic changed, and the cache assertions are untouched.
Tests. test/map-cache.test.ts passed in each of four local runs (three before the change, one after), about 6 s each. I did not run the full suite.
Left out. I didn't change the timing assertion in the warm-cache test. It is a ratio of two timings taken on the same machine, so load doesn't change its verdict.
To check. After this lands, the sentinel cause shared:01m23vygyffx5hg2f5vm8r74sr:3fvet6f1u6 should leave the degraded list. If it comes back, the failing hook is a different one.
🤖 Generated with Claude Code
Test-only change: the three afterAll hooks that stop the server, close apps and remove temp dirs now get 60 s instead of bun's 5 s default, matching the 60–120 s the beforeAll hooks already have. No product code, security, or UI surface is touched, so there is nothing for the phone, keyboard or no-JS checks to find. The scope is right and nothing is added that was not asked.
Two things I would do next:
- The cause is a guess (the PR says so). If the sentinel cause returns after this lands, look at the beforeAll in the warm suite or the 5 s p95 guard, and capture the hook name in the log.
- The top-level afterAll and the two suite hooks now share one magic 60_000. A named constant would keep them from drifting.
This pull changes the
/map after a writesuite'safterAllteardown hooks intest/map-cache.test.tsto get a 60 s timeout. That is my best guess at the cause, and I couldn't reproduce the failure.Cause. The failure was reported as "(unnamed)", which points to a setup or teardown hook rather than one of the three tests. The setup hooks already had 60–120 s timeouts. The two teardown hooks had none, so bun's 5 s default applied. They stop the server, close the apps and delete the temp directories, and that can overrun 5 s on a loaded check machine. I did not confirm that this is what failed in the three red pulls.
Change. Both teardown hooks now have the same 60 s timeout. No test logic changed, and the cache assertions are untouched.
Tests.
test/map-cache.test.tspassed in each of four local runs (three before the change, one after), about 6 s each. I did not run the full suite.Left out. I didn't change the timing assertion in the warm-cache test. It is a ratio of two timings taken on the same machine, so load doesn't change its verdict.
To check. After this lands, the sentinel cause
shared:01m23vygyffx5hg2f5vm8r74sr:3fvet6f1u6should leave the degraded list. If it comes back, the failing hook is a different one.🤖 Generated with Claude Code
Closes #3059