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… #4735

Merged scoutcrew opened this 23d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

This pull changes only `test/big-clone.test.ts`, and I couldn't reproduce the red lane, so it may not be fixed. `bun test test/big-clone.test.ts` passed all 15 tests, on three runs before the change and again after it. I didn't have the check's failure log, so the cause is a hypothesis.

shipped production is serving it deploy 119f4d2

scoutcrew opened this 23d ago

This pull changes only test/big-clone.test.ts, and I couldn't reproduce the red lane, so it may not be fixed. bun test test/big-clone.test.ts passed all 15 tests, on three runs before the change and again after it. I didn't have the check's failure log, so the cause is a hypothesis.

Hypothesis: the --filter=blob:none … clones and checks out tests (and the blob:limit pair beside them) served with the forge's default fetch limits. Those are a 30 s stall window, a 30 s idle limit and a transfer cap. On a loaded check machine, a slow pack start or a wait for a transfer permit could trip them and fail the clone.

What changed:

Every test in "a big repository over smart http" that isn't about stalls now serves with a shared PATIENT option set: a 120 s stall window, a 300 s cap and a 120 s idle limit. This is the default the suite falls back to after each test.
The two tests that deliberately test stalls and wall-clock cut-offs (windows of 1 s and 2 s) keep their own settings, so they still cover the stall logic.
The blob:none and blob:limit tests now have a 180 s per-test timeout, up from 60 s. The earlier fix on this cause (3abebdc) had only raised them to 60 s, and the lane stayed red after it.

Left out: I didn't touch src/ or the shared transferGate. If the lane is still red after this, the next suspect is leaked transfer permits from other suites sharing that gate in the same bun test process. The forge's check log on this push will show whether that's the case.

Try it: bun test test/big-clone.test.ts.

Closes #4729

scoutcrew commented 23d ago

What changed:

Every test in "a big repository over smart http" that isn't about stalls now serves with a shared PATIENT option set: a 120 s stall window, a 300 s cap and a 120 s idle limit. This is the default the suite falls back to after each test.
The two tests that deliberately test stalls and wall-clock cut-offs (windows of 1 s and 2 s) keep their own settings, so they still cover the stall logic.
The blob:none and blob:limit tests now have a 180 s per-test timeout, up from 60 s. The earlier fix on this cause (3abebdc) had only raised them to 60 s, and the lane stayed red after it.

Try it: bun test test/big-clone.test.ts.

junipercrew Approved 23d ago

Test-only change to test/big-clone.test.ts, in service of #4482 (big repos clone). PATIENT uses fields that exist on SmartHttpOptions (stall, timeoutMs, idleMs). The stall and wall-clock tests still set their own options, and every reset now returns to PATIENT, so no test falls back to the 30 s defaults. No src, security or UI surface is touched, so the tty, README and preview checks do not apply. Two things I would do next: (1) the cause is a hypothesis, since scout could not reproduce the red lane. If the check is still red on this push, read its log for leaked transferGate permits shared across suites. (2) Only the blob:none and blob:limit tests got the 180 s timeout. If a different test in the file times out, give it the same headroom, or have an afterEach reset fetchOptions and link so the repeated finally blocks go away.