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 6 pulls in the last hour — the lane's red, not theirs; they wait … #4500
Check · Review · Land · Live done — Landed and live in production.
This is a best guess at the cause, not a confirmed fix. I couldn't see the failing check log, and the test passes here with or without the change (9 of 9).
shipped production is serving it deploy 2fa0c24
This is a best guess at the cause, not a confirmed fix. I couldn't see the failing check log, and the test passes here with or without the change (9 of 9).
Cause. The sentinel names migrate: after > (unnamed). A test with no name is a setup or teardown hook, not one of the nine tests. The only hook that touches the disk after other processes have run is afterAll, which removes the temp data directory with a single rm. On a loaded check machine, a mirror push or a git child process can still be writing into that directory when rm runs. rm then fails with ENOTEMPTY, and the suite goes red even though no behaviour is wrong. The fake-origin and git work in the test is otherwise self-contained.
Change. In test/migrate-after.test.ts, the afterAll teardown now calls rm with maxRetries: 20, retryDelay: 100. A late write no longer fails the hook. No product code changed.
Not done. I did not make startMirrorOut wait for in-flight pushes before it stops. That would be a larger change to production code than this fix needs. If the sentinel cause persists after this lands, the failure is somewhere else, and the next check log will show where.
Try it. bun test test/migrate-after.test.ts.
One-line teardown hardening in test/migrate-after.test.ts: rm in afterAll now retries ENOTEMPTY (20 x 100ms). No product code, no new dependency, no security surface, nothing for the page or terminal. It is a lane-red fix for a sentinel, so it does not widen scope. The cause is a plausible guess from the unnamed hook (afterAll is the only hook touching disk after git children run); the pull says so honestly. Preview is unaffected by a test-only change.
Two things I would do next: (1) if the sentinel recurs, make stopMirror/startMirrorOut await in-flight pushes so teardown is deterministic instead of retried; (2) if other suites share this teardown shape, put the retrying rm in one shared test helper rather than repeating the options.
This is a best guess at the cause, not a confirmed fix. I couldn't see the failing check log, and the test passes here with or without the change (9 of 9).
Cause. The sentinel names
migrate: after > (unnamed). A test with no name is a setup or teardown hook, not one of the nine tests. The only hook that touches the disk after other processes have run isafterAll, which removes the temp data directory with a singlerm. On a loaded check machine, a mirror push or a git child process can still be writing into that directory whenrmruns.rmthen fails withENOTEMPTY, and the suite goes red even though no behaviour is wrong. The fake-origin and git work in the test is otherwise self-contained.Change. In
test/migrate-after.test.ts, theafterAllteardown now callsrmwithmaxRetries: 20, retryDelay: 100. A late write no longer fails the hook. No product code changed.Not done. I did not make
startMirrorOutwait for in-flight pushes before it stops. That would be a larger change to production code than this fix needs. If the sentinel cause persists after this lands, the failure is somewhere else, and the next check log will show where.Try it.
bun test test/migrate-after.test.ts.Closes #4498