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 6 pulls in the last hour — the lan… #4512
Check · Review · Land · Live done — Landed and live in production.
I think I found the cause of the flaky hook and fixed it in `test/member-crew.test.ts`. I couldn't reproduce the failure here, so the fix is a diagnosis, not a confirmed cure.
shipped production is serving it deploy 749c831
I think I found the cause of the flaky hook and fixed it in test/member-crew.test.ts. I couldn't reproduce the failure here, so the fix is a diagnosis, not a confirmed cure.
What changed: the suite's afterAll stopped the servers and then deleted the temp data dir, but it never closed the app. The app's background pollers and the open SQLite handle could still be writing while the delete ran. On a loaded check machine that can fail the hook as "(unnamed)". The hook now stops the servers, calls app.close(), then removes the directory. This is the same teardown order test/roles.test.ts uses.
The earlier fix for this cause (#4470) only raised the hook timeouts. That didn't help, since the issue reports it failing on 6 pulls since then.
Checks: bun test test/member-crew.test.ts passes (2 tests, about 0.8 s). I ran it three times before the change and once after. tsc --noEmit is clean. The commit is pushed, but I have not seen the forge's check run on it.
Not done: I left the other 500+ suites' teardown alone. This test is the only one the sentinel named.
To confirm: once main goes green, check that shared:01m23vygyffx5hg2f5vm8r74sr:231tqr2lww is gone from the degraded list.
Teardown now matches test/roles.test.ts: servers.stop() (synchronous, so dropping the await is right), then app.close() (aborts pollers, closes readers and the db), then rm. That removes the plausible race of the delete against a live SQLite handle. No product code touched, no security surface, no new dependency. Caveat: the cause is a diagnosis, not a reproduced failure, so confirm the sentinel clears. Next: (1) if it recurs, run the same fix in other suites that call createApp without close; (2) consider a shared teardown helper in test/helpers so the order lives in one place.
I think I found the cause of the flaky hook and fixed it in
test/member-crew.test.ts. I couldn't reproduce the failure here, so the fix is a diagnosis, not a confirmed cure.What changed: the suite's
afterAllstopped the servers and then deleted the temp data dir, but it never closed the app. The app's background pollers and the open SQLite handle could still be writing while the delete ran. On a loaded check machine that can fail the hook as "(unnamed)". The hook now stops the servers, callsapp.close(), then removes the directory. This is the same teardown ordertest/roles.test.tsuses.The earlier fix for this cause (#4470) only raised the hook timeouts. That didn't help, since the issue reports it failing on 6 pulls since then.
Checks:
bun test test/member-crew.test.tspasses (2 tests, about 0.8 s). I ran it three times before the change and once after.tsc --noEmitis clean. The commit is pushed, but I have not seen the forge's check run on it.Not done: I left the other 500+ suites' teardown alone. This test is the only one the sentinel named.
To confirm: once main goes green, check that
shared:01m23vygyffx5hg2f5vm8r74sr:231tqr2lwwis gone from the degraded list.Closes #4504