Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:3s8z6cbut9 is past its budget: trevato/forge: "migrate: after > (unnamed)" failed on 3 pulls in the last hour — the lane's red, not theirs; they wait … #4474
Check · Review · Land · Live done — Landed and live in production.
I changed `test/migrate-after.test.ts` so its hooks and tests no longer fail when the check machine is slow. I couldn't reproduce the red check here, so I inferred the cause. `bun test test/migrate-after.test.ts` passes locally (9 tests), and the pull is pushed, but the forge's check hasn't run on it yet.
shipped production is serving it deploy 4c3a9d3
I changed test/migrate-after.test.ts so its hooks and tests no longer fail when the check machine is slow. I couldn't reproduce the red check here, so I inferred the cause. bun test test/migrate-after.test.ts passes locally (9 tests), and the pull is pushed, but the forge's check hasn't run on it yet.
The failing "(unnamed)" entry is a hook, not a named test. I think it was the afterAll hook, which has no timeout of its own and so got bun's 5 s default. It stops servers and removes a temp directory, which can be slow on a loaded machine. The test bodies, which run git and a fake forge, had the same 5 s default.
- Timeouts:
setDefaultTimeout(30_000)at the top of the file, plus an explicit 30 s onafterAll, matching the existingbeforeAll. - Polling: the two loops that wait for the mirror push now allow up to 30 s (600 tries at 50 ms) instead of 5 s.
I changed no assertions and no application code.
To check it, watch whether "migrate: after > (unnamed)" fails again on later pulls and the sentinel's degraded cause clears. If it still fails, the log will name the hook. Pulls that were red only on this test wait for main's next green check.
Test-only change, in line with priority 1 (stability): it widens the timeouts of test/migrate-after.test.ts (default 30 s, explicit 30 s on afterAll, polling loops 5 s -> 30 s) and touches no assertion, no app code and no dependency. There is no UI or security surface, so the preview has nothing to exercise. The polling loops still exit as soon as the condition holds, so a fast machine pays nothing. The cause is inferred, not reproduced, and the author says so.
Two things I would do next:
- If "migrate: after > (unnamed)" fails again, read the hook name from the log and fix what makes teardown slow (leaked servers or git processes). More timeout would only hide it.
- Move the 30 s polling into a shared helper in test/helpers so the two loops and future tests stop copying the 600 x 50 ms constants.
I changed
test/migrate-after.test.tsso its hooks and tests no longer fail when the check machine is slow. I couldn't reproduce the red check here, so I inferred the cause.bun test test/migrate-after.test.tspasses locally (9 tests), and the pull is pushed, but the forge's check hasn't run on it yet.The failing "(unnamed)" entry is a hook, not a named test. I think it was the
afterAllhook, which has no timeout of its own and so got bun's 5 s default. It stops servers and removes a temp directory, which can be slow on a loaded machine. The test bodies, which run git and a fake forge, had the same 5 s default.setDefaultTimeout(30_000)at the top of the file, plus an explicit 30 s onafterAll, matching the existingbeforeAll.I changed no assertions and no application code.
To check it, watch whether "migrate: after > (unnamed)" fails again on later pulls and the sentinel's degraded cause clears. If it still fails, the log will name the hook. Pulls that were red only on this test wait for main's next green check.
Closes #4454