GeezerVison

Problem

Bun patch compatibility is the slowest compatibility workflow (median ~22 min wall-clock per run) and had 3 re-runs of the same SHA in the last ~22 h (out of 68 runs). In each one, the first attempt's native leg failed one cell on a manifest-less VEX check:

None of these cells was retried, even though the harness already has a fresh-cell retry (retry_network_cell, 3 tries) for explicit transport failures. Every re-run of the same SHA passed.

Root cause

retry_network_cell only retries when has_transport_failure(row) finds a transport error string in the row. The VEX block threw away the evidence:

• vex() stored only exit / skip / attested. A record fetch that fails in transport surfaces only in the envelope's warnings[] (Could not fetch patch <uuid>: Network error: error sending request for url (...)), and the skip code (record_unavailable) is the same for every cause. vexLedgersDeleted is the step that has to fetch the record from the patch API, because its ledgers were deleted.
• The checkout's bun install --frozen-lockfile output (bun reports error: ConnectionRefused downloading tarball <spec> / error: GET <url> - 5xx) went to vex-install.log and never reached the row.

So a patch API or patch.socket.dev blip during these steps failed the job for good, and the only way out was a manual re-run of the whole ~22-minute workflow.

Fix

scripts/backtest-bun.py only:

• Each vex run now keeps its warnings[].detail strings in row['vex'][label]['warnings'].
• The VEX checkout install keeps just the lines bun uses to report a transport failure (row['vexInstallTransport']).
• has_transport_failure also recognises bun's own fetch-failure lines. These are connection errors (Connection*, FailedToOpenSocket, Timeout "downloading …") and GET <url> - 5xx.

The retry stays as narrow as before. It only runs on an explicit transport error or a 5xx. A 404, a frozen-lock drift, or an attestation mismatch still fails the cell immediately. No timeouts were raised and no checks were removed or weakened.

Proof

All checks were run locally against the CLI built from this tree, with patches-api pointed at a closed port:

• vex --json on a hosted-wired checkout exits 1 with warnings: ["Could not fetch patch 3b1f…: Network error: error sending request for url (http://127.0.0.1:1/patch/view/3b1f…): client error (Connect): tcp connect error: Connection refused (os error 111)"]. Under the old row shape has_transport_failure returned False; under the new one it returns True.
• bun 1.3.14 installing from an unreachable tarball URL prints error: ConnectionRefused downloading tarball minimist@http://127.0.0.1:9/..., and bun_transport_failures picks it up. A GET … - 503 line matches; GET … - 404 and lockfile had changes, but lockfile is frozen do not.
• I simulated retry_network_cell with a row that fails vexLedgersDeleted on a connection reset and then passes. It retried once and returned passed=True, keeping networkRetryAttempts.
• ruff check --select F,E9 shows the same single pre-existing finding as on main.

This PR touches scripts/backtest-bun*.py, so it triggers the full Bun workflow; that run is the end-to-end check.

Where tests run

Unchanged. No test, cell or job was removed or moved, and required-check names are untouched.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WLdPQLaBvre5kBJ8iD148S

Generated by Claude Code

Generated by Claude Code