Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:32cb1ovnai was degraded 56 minutes today: trevato/forge: "a big repository over smart http > --filter=blob:none over protocol v2 clones and checks out" failed on… #4865

I couldn't fix the cause of these failures because their logs never recorded it. This pull changes the failing tests so that the next failure, if one comes, prints why.

What the run history shows. The test failed four times: on #4649, #4646, #4650 and #4657, between 21:33 and 21:57 UTC on 2026-10-21. All four pulls only changed styles. Other pulls on the same main commits passed in the same window. Each failure was a clone that exited with code 128 in about 370 ms. Nothing has failed since then: I checked every run back to 13:48, plus the checks of open and recently merged pulls, and this test passed every time I could see it (some red runs list only their first few failing tests). Three local runs of test/big-clone.test.ts all passed (15 of 15).

Why the earlier fixes don't explain it. 3abebdc (#4680) and eab3323 (#4735) both gave the test more time. A failure in 370 ms is not a timeout, so the problem was something else, probably on the check machine during those 25 minutes. The 56 minutes in this issue are from that same window, before either fix.

What changed. Only test/big-clone.test.ts. The three clones that are expected to succeed and only checked the exit code (the short-pause clone, blob:limit=1m and blob:none) are now checked with expect(run).toMatchObject({ code: 0 }). A failure now prints git's whole output, including its error text, not just Expected: 0, Received: 128. Passing behaviour is the same, and no test was loosened.

Not done. The server side of the git transfer still discards git's error output (stderr: "ignore" in src/git/smart-http.ts). Logging that would change the product, not the test, so I left it alone. If the failure comes back, the new output should show which side failed.

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

🤖 Generated with Claude Code

Closes #4785

I couldn't fix the cause of these failures because their logs never recorded it. This pull changes the failing tests so that the next failure, if one comes, prints why.

What the run history shows. The test failed four times: on #4649, #4646, #4650 and #4657, between 21:33 and 21:57 UTC on 2026-10-21. All four pulls only changed styles. Other pulls on the same main commits passed in the same window. Each failure was a clone that exited with code 128 in about 370 ms. Nothing has failed since then: I checked every run back to 13:48, plus the checks of open and recently merged pulls, and this test passed every time I could see it (some red runs list only their first few failing tests). Three local runs of test/big-clone.test.ts all passed (15 of 15).

Why the earlier fixes don't explain it. 3abebdc (#4680) and eab3323 (#4735) both gave the test more time. A failure in 370 ms is not a timeout, so the problem was something else, probably on the check machine during those 25 minutes. The 56 minutes in this issue are from that same window, before either fix.

What changed. Only test/big-clone.test.ts. The three clones that are expected to succeed and only checked the exit code (the short-pause clone, blob:limit=1m and blob:none) are now checked with expect(run).toMatchObject({ code: 0 }). A failure now prints git's whole output, including its error text, not just Expected: 0, Received: 128. Passing behaviour is the same, and no test was loosened.

Not done. The server side of the git transfer still discards git's error output (stderr: "ignore" in src/git/smart-http.ts). Logging that would change the product, not the test, so I left it alone. If the failure comes back, the new output should show which side failed.

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

🤖 Generated with Claude Code

When it does fail again, this test will now print git's error output, not just the exit code. The cause of the 56 minutes can't be fixed yet because the failure logs never captured it. The new comment on the issue is only automatic triage filing it under P0 Trust, so nothing in the work changes. The branch is pushed at 3c3f39a and matches origin.

What the run history shows. The test failed on four pulls between 21:33 and 21:57 UTC on 2026-10-21: #4649, #4646, #4650 and #4657. All four only changed styles. Other pulls on the same main commits passed in the same window. Each failure was a clone that exited with code 128 after about 370 ms. Nothing has failed since: every check run back to 13:48 that lists the test passes it, including the open and recently merged pulls. Some red runs list only their first few failing tests, so I can't rule those out completely. Three local runs of test/big-clone.test.ts passed 15 of 15.

Why the earlier fixes didn't explain it. 3abebdc (#4680) and eab3323 (#4735) both gave the test more time. A failure in 370 ms is not a timeout, so the cause was something else. It was most likely on the check machine during those 25 minutes, but that is a guess. The 56 minutes in this issue fall inside that window, so they come from failures that happened before either fix.

What changed. Only test/big-clone.test.ts. Three clones that must succeed used to check only the exit code: the short-pause clone, blob:limit=1m and blob:none. They now check expect(run).toMatchObject({ code: 0 }). A failure prints git's whole result, including its error text, rather than just Expected: 0, Received: 128. Passing behaviour is the same, and no test was loosened.

Not done. On the server side, the git process's error output is still thrown away (stderr: "ignore" in src/git/smart-http.ts). Logging it would change the product rather than the test, so I left it. If the failure returns, the new output should at least show what the client side reported.

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

🤖 Generated with Claude Code