Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:32cb1ovnai is past its budget: trevato/forge: "a big repository over smart http > --filter=blob:none over protocol v2 clones and checks out" failed on… #4680
Check · Review · Land · Live done — Landed and live in production.
I changed the timeout on the two partial-clone tests in `test/big-clone.test.ts`. I have not confirmed this was the cause of the failures.
shipped production is serving it deploy 97ab7b8
I changed the timeout on the two partial-clone tests in test/big-clone.test.ts. I have not confirmed this was the cause of the failures.
I didn't have the failing check's log, so I inferred the cause from the test. --filter=blob:none over protocol v0 and v2 each clone and then fetch a 4 MiB blob lazily on checkout. Neither set a timeout, so they ran on bun's 5 s default. Every other network test in that file has 60 s. On a loaded check machine, the default can expire even though the code is fine.
Both tests now get 60_000, the same budget as their siblings. The --filter=blob:limit=1m test I changed is the neighbouring loop test, so it now gets the same budget too.
bun test test/big-clone.test.ts passes: 15 tests, 0 failures, 16 s. It passed before the change too, so it can't show the fix works under load. The forge's check on this push is the real test.
I changed only the test, not src/git/smart-http.ts or the stall logic. If the failure comes back, it is not just the 5 s default, and the check log would be the next thing to read.
Test-only change: the two protocol-loop tests (blob:limit=1m and blob:none) were the only network tests in test/big-clone.test.ts still on bun's 5 s default, while every sibling has 60_000. Giving them the same budget is the right, minimal fix for a flaky timeout on a loaded check machine, and it serves #4482 (big repos clone) without touching src. No security, door, dependency or dead-code concerns; the preview has nothing to show for a test change. The scout is honest that the cause is inferred, not confirmed. Two next steps: (1) if the check fails again, read its log for the real duration before raising the number further; (2) consider a shared constant for the 60_000 budget so new tests in this file do not forget it.
I changed the timeout on the two partial-clone tests in
test/big-clone.test.ts. I have not confirmed this was the cause of the failures.I didn't have the failing check's log, so I inferred the cause from the test.
--filter=blob:none over protocol v0andv2each clone and then fetch a 4 MiB blob lazily on checkout. Neither set a timeout, so they ran on bun's 5 s default. Every other network test in that file has 60 s. On a loaded check machine, the default can expire even though the code is fine.Both tests now get
60_000, the same budget as their siblings. The--filter=blob:limit=1mtest I changed is the neighbouring loop test, so it now gets the same budget too.bun test test/big-clone.test.tspasses: 15 tests, 0 failures, 16 s. It passed before the change too, so it can't show the fix works under load. The forge's check on this push is the real test.I changed only the test, not
src/git/smart-http.tsor the stall logic. If the failure comes back, it is not just the 5 s default, and the check log would be the next thing to read.Closes #4679