Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:2ks1dt3lq8 is past its budget: trevato/forge: "a frozen mirror is said, and reconnected in one click > (unnamed)" failed on 5 pulls in the last hour —… #4520
Check · Review · Land · Live done — Landed and live in production.
This pull stops machine load from failing "a frozen mirror is said, and reconnected in one click". I couldn't reproduce the red here, so the cause is inferred. The file passes locally (12 tests) in about 2 seconds, but that doesn't show the fix works under load.
shipped production is serving it deploy 47e6991
This pull stops machine load from failing "a frozen mirror is said, and reconnected in one click". I couldn't reproduce the red here, so the cause is inferred. The file passes locally (12 tests) in about 2 seconds, but that doesn't show the fix works under load.
The failure was labelled "(unnamed)", which fits a hook timing out rather than an assertion failing. The earlier fix (#4475) only closed the race where a background sync wrote into a directory being deleted. Nothing there addressed Bun's 5 s default timeout. Those tests clone, sync and wait on background syncs, and the afterAll waits for syncs to settle and removes three directories, so a busy check machine can pass the 5 s limit without any fault in the code.
Change: in test/origins-reconnect.test.ts, setDefaultTimeout(60_000) now covers every test in the file, and the afterAll has an explicit 60 s timeout. No source files changed, and no assertions changed or were loosened.
Left out: the polling loops inside the tests keep their own 10–15 s limits. I didn't find them to be the cause. If this cause stays on the degraded list after the next red runs, they are the next place to look.
To try it: bun test test/origins-reconnect.test.ts
Test-only change: a 60 s default timeout for the file and an explicit 60 s on the afterAll. No source, assertion or dependency changes, so security, both-doors and README are untouched. The fix targets the right place: an unnamed failure in a hook that clones and syncs is what a 5 s timeout looks like on a loaded check machine. The in-test polling loops (10-15 s) sit well inside 60 s. Next, in order: 1) The cause is inferred, not reproduced. If this test is still on the degraded list after the next red runs, log how long the afterAll takes and look at the polling loops. 2) bun's setDefaultTimeout is process-wide once called, so it may lengthen the timeout for files that run after this one in the same bun test process. Check that, or move the long timeouts onto the individual tests and hooks that need them.
This pull stops machine load from failing "a frozen mirror is said, and reconnected in one click". I couldn't reproduce the red here, so the cause is inferred. The file passes locally (12 tests) in about 2 seconds, but that doesn't show the fix works under load.
The failure was labelled "(unnamed)", which fits a hook timing out rather than an assertion failing. The earlier fix (#4475) only closed the race where a background sync wrote into a directory being deleted. Nothing there addressed Bun's 5 s default timeout. Those tests clone, sync and wait on background syncs, and the
afterAllwaits for syncs to settle and removes three directories, so a busy check machine can pass the 5 s limit without any fault in the code.Change: in
test/origins-reconnect.test.ts,setDefaultTimeout(60_000)now covers every test in the file, and theafterAllhas an explicit 60 s timeout. No source files changed, and no assertions changed or were loosened.Left out: the polling loops inside the tests keep their own 10–15 s limits. I didn't find them to be the cause. If this cause stays on the degraded list after the next red runs, they are the next place to look.
To try it:
bun test test/origins-reconnect.test.tsCloses #4516