GeezerVison

Problem

The coverage job (and with it ci-ok, a required check that also gates the merge queue) failed on PR #1652 at 4f7319c, job 119029890773, for a reason unrelated to the PR:

e2e_redirect_cargo_build (main): ... panicked at crates/socket-patch-cli/tests/e2e_redirect_cargo_build.rs:847:9:
(4b) the reverted checkout fetches from crates.io:
warning: spurious network error (3 tries remaining): [7] Could not connect to server (Failed to connect to static.crates.io port 443 after 5001 ms)
warning: spurious network error (2 tries remaining): ...
warning: spurious network error (1 try remaining): ...
error: failed to download from `https://static.crates.io/crates/cfg-if/1.0.5/download`

This is the same crates.io blip class #1459 fixed for the required cargo … lock-v* legs. Over the last ~200 CI runs (since 2026-10-12) it is the only infrastructure failure of coverage; the other coverage/ci-ok reds were real PR failures. In the merge queue one such blip evicts the entry and costs a full rebuild.

Root cause

#1459 widened cargo's net.retry only when SOCKET_PATCH_CARGO_E2E_REQUIRED is set. The coverage job runs the same real-cargo suites (e2e_redirect_cargo_build, e2e_redirect_cargo_shapes, e2e_vendor_cargo_build, mode_migration_cargo, e2e_safety_cargo_build) as optional, so their cargo children keep the default net.retry=3 (~11s). Optional mode soft-skips only the baseline fixture build; later fetches such as the (4b) revert's cargo fetch --locked are hard assertions, so a blip after the baseline succeeded fails the job.

Fix

cargo_e2e_matrix::cargo_command sets CARGO_NET_RETRY=10 (~80s of cargo's own backoff) when CI is set too, not only on required legs. GitHub Actions always sets CI=true. Optional local runs still keep the default, so an offline machine still skips quickly. An ambient CARGO_NET_RETRY still wins. The old-cargo 127.0.0.1:9 proxy check builds its own Command with CARGO_NET_RETRY=0, so it is unaffected. Only errors cargo classifies as spurious are retried. Checksum, resolver and --locked failures still fail at once.

Proof

• With a logging cargo shim on PATH, cargo test -p socket-patch-cli --test e2e_redirect_cargo_build:
  • CI unset: all 13 cargo children (build ×4, fetch ×5, run, --version ×3) see CARGO_NET_RETRY unset, as before.
  • CI=true: all 13 see CARGO_NET_RETRY=10.
  • 23 passed in both runs.
• Ride out crates.io blips in required cargo e2e legs #1459 measured the retry window for this exact error ([7] Could not connect ... after 0 ms): retry=3 fails after 12s, retry=10 rides out a simulated 20s blip and succeeds after 21s.
• rustfmt --check is clean on the touched file. cargo clippy -D warnings reports nothing in it. The pre-existing errors in tests/common/mod.rs and tests/prebuilt_common/mod.rs are unchanged.

No tests removed or moved.

https://claude.ai/code/session_017UzN47eRAtVax9Sbom2ffx

Generated by Claude Code