Repository navigation
windows-latest: storage-policy selection tests exceed Bun's 5s default timeout (6-8s on CI, 144ms locally) #727
Description
windows-latest fails reproducibly on dev in tests/storage-policy.test.ts, and it survives a rerun — so this is not the Bun panic flake or the old 12-minute ceiling, it is a real Windows-only slowdown.
Evidence
Run 30507689929 at ef805c3cf, after a --failed rerun:
(fail) selection helpers > selectPolicyPreview backfills percent past pending oldest archive [7065.76ms]
(fail) selection helpers > selectPolicyPreview reduceToBytes skips pending oldest and keeps backfilling [7636.14ms]
(fail) selection helpers > selectPolicyPreview honors removeOldestPercent [6224.78ms]
(fail) selection helpers > selectPolicyPreview honors reduceToBytes via oldest files [7949.32ms]
(fail) runStorageCleanupPolicy > disabled never calls execute [7529.87ms]
The first attempt on the same head failed three of these with the same 5-8s durations, so it reproduces rather than flaking. Locally the entire file is 22 pass in 144ms — roughly a 50x gap. Every failing case sits between 6 and 8 seconds against Bun's default 5s harness timeout, which is the whole story: these are timeouts, not assertion failures.
Why it is a timeout and not a logic bug
The sibling suite tests/storage-cleanup.test.ts already carries explicit per-test budgets for exactly this reason — { timeout: 20_000 } at three sites, { timeout: 30_000 } at another, with a comment noting that seeding "trips bun's default 5s harness timeout". tests/storage-policy.test.ts does the same kind of filesystem seeding but has no equivalent budget, so it inherits the 5s default and loses on a slow Windows filesystem.
Suggested fix
Give the seeding-heavy cases in storage-policy.test.ts the same explicit budget the cleanup suite uses. That is a test-harness fix, not a product change — nothing here indicates the selection logic is wrong.
Worth also asking whether the shared seedHome helper can be made cheaper (fewer real file writes, or a tmpfs-style layout), since paying 6-8s per case on Windows will keep biting as more cases are added.
Context
Found while landing #646 and stabilising dev. Not caused by that work: the failures live in tests/storage-policy.test.ts and src/storage/*, while the merged changes touched src/providers/registry.ts, the Cursor adapter, scripts/generate-jawcode-metadata.ts, and docs. Run 30505367421 shows all six jobs green a few commits earlier, so this surfaces intermittently depending on runner speed — but when the runner is slow it is deterministic, not random.
Activity
github-actions commentedon Jul 30, 2026
Automated translation bookkeeping — detected language: English.
lidge-jun commentedon Jul 30, 2026
Update: not reproduced on the newest
devhead. Run 30509630276 at67c731e65is green on all six jobs,windows-latestincluded.So this is runner-speed dependent rather than constant — which is worth stating precisely, because it changes how the failure reads:
--failedrerun. That is not flake behaviour.Leaving this open. An intermittently-green timeout is still a latent failure: the margin is the problem, not the outcome of any single run, and
tests/storage-policy.test.tsstill lacks the explicit budget its siblingstorage-cleanupsuite already carries at{ timeout: 20_000 }/{ timeout: 30_000 }. Locally the whole file is 22 pass in 144ms, so the fix is cheap and there is no reason to wait for it to bite again.test(storage): give the policy suite an explicit harness budget
test(storage): give the policy suite an explicit harness budget (#732)
lidge-jun commentedon Jul 30, 2026
Fixed on
devin 60e1004 (#732).The fix is the one suggested here:
tests/storage-policy.test.tsnow carries anexplicit harness budget. It went in as a single file-level
setDefaultTimeout(30_000)rather than per-case options — one call covers allfifteen
seedHomesites, andsetDefaultTimeout(30_000)is already theconvention in five other suites here (
grok-management-api,codex-history-provider,claude-management-api,server-combo-failover-e2e,subagent-fallback-handle-responses).Mechanism proven before patching
The suspicion in the issue was that these are timeouts, not assertion failures.
Confirmed in isolation, under CI's
--isolatemode:A 6s case dies at exactly 5000ms without a budget. That is the shape of the five
failures in run 30507689929, all of which sat between 6s and 8s.
Verification
Local:
bun x tsc --noEmitexit 0,bun test --isolate tests/storage-policy.test.ts22 pass / 0 fail / 91 expect() calls in 95ms.
CI on the PR head — run 30512174098, all ten checks pass:
The
windows-latestlog matters more than its conclusion. The five cases thatfailed in 30507689929 now read:
Sub-300ms on the runner that drew this ticket. That is worth stating plainly:
this particular Windows runner was fast, so those cases would have passed
even without the change. The fix removes the margin, it does not prove the slow
runner is gone. That is exactly why the budget belongs in the file — an
intermittently-green timeout is a latent failure, as noted in the update above.
Not fixed here
Windows still pays ~2.5x for this suite (10m45s vs 4m27s on ubuntu). Raising a
budget hides a margin; it does not close a gap. The suspect remains
bun test --isolateinci.yml, which is CI-only and absent from the localtestscript — per-test process isolation is expensive on Windows. Turning itoff trades test-isolation guarantees for speed, so it is an owner call rather
than something to fold into a timeout fix. Making
seedHomecheaper (fewer realwrites) is the other candidate raised in this issue and is still open as an
option.
test(storage): give the policy suite an explicit harness budget (lidg…