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… #4531
Check · Review · Land · Live done — Landed and live in production.
I changed the teardown in `test/member-crew.test.ts`, but I never reproduced the failure, so this is a likely fix and not a confirmed one. The sentinel only names the failing hook as "(unnamed)". The test passed every time I ran it here, in about 0.6 s, and `tsc --noEmit` is clean. I have not seen the forge's check run on the push yet.
shipped production is serving it deploy da65c36
I changed the teardown in test/member-crew.test.ts, but I never reproduced the failure, so this is a likely fix and not a confirmed one. The sentinel only names the failing hook as "(unnamed)". The test passed every time I ran it here, in about 0.6 s, and tsc --noEmit is clean. I have not seen the forge's check run on the push yet.
Two earlier fixes (#4470 and #4512) raised the hook timeouts and added app.close(). Password hashing is already cut to argon2's cheapest setting in tests, so it isn't the load-sensitive part. The remaining machine-dependent step is the afterAll removal of the data directory. A request still in flight can write into the directory while rm runs, which fails with ENOTEMPTY on a loaded machine.
- Drain first:
afterAllnow awaitsservers.stopAccepting(2_000)beforeservers.stop()andapp.close(). - Retry the removal:
rmnow retries (maxRetries: 20,retryDelay: 100), the same waytest/migrate-after.test.tsdoes.
I left the test's assertions and timeouts alone. If the sentinel cause persists after this lands, the next step is to capture the actual hook error from a failing check log.
To try it: bun test test/member-crew.test.ts.
Test-only teardown change: drain in-flight requests via the real Servers.stopAccepting (exists, polls pendingRequests), then stop, close, and rm with retries as test/migrate-after.test.ts already does. No product surface touched; no security, terminal, or README impact. The fix is unconfirmed (the author never reproduced the failure), which is honest and fine. Two next steps: (1) if the sentinel recurs, capture the real hook error from the check log rather than raising timeouts again; (2) consider a shared test helper for drain-then-remove teardown, since two suites now repeat the pattern.
I changed the teardown in
test/member-crew.test.ts, but I never reproduced the failure, so this is a likely fix and not a confirmed one. The sentinel only names the failing hook as "(unnamed)". The test passed every time I ran it here, in about 0.6 s, andtsc --noEmitis clean. I have not seen the forge's check run on the push yet.Two earlier fixes (#4470 and #4512) raised the hook timeouts and added
app.close(). Password hashing is already cut to argon2's cheapest setting in tests, so it isn't the load-sensitive part. The remaining machine-dependent step is theafterAllremoval of the data directory. A request still in flight can write into the directory whilermruns, which fails with ENOTEMPTY on a loaded machine.afterAllnow awaitsservers.stopAccepting(2_000)beforeservers.stop()andapp.close().rmnow retries (maxRetries: 20,retryDelay: 100), the same waytest/migrate-after.test.tsdoes.I left the test's assertions and timeouts alone. If the sentinel cause persists after this lands, the next step is to capture the actual hook error from a failing check log.
To try it:
bun test test/member-crew.test.ts.Closes #4527