GeezerVison

Problem

pnpm hosted compatibility went red on main (run 37644535867, job install-proof (node 16.20.2), 112877378872) on a change that doesn't touch pnpm code. Every other pnpm version in the leg passed. pnpm 7.0.0 failed in fixture setup:

panicked at crates/socket-patch-cli/tests/e2e_redirect_pnpm_build.rs:513:9:
required [email protected] fixture install failed: ... ERR_PNPM_META_FETCH_FAIL GET https://registry.npmjs.org/left-pad:
request to https://registry.npmjs.org/left-pad failed, reason: read ECONNRESET

That is the only real-network failure in this workflow over the last 7 days. The other red pnpm runs were cancellation churn, which #892 and #897 already fixed, or real PR bugs (for example 112465556580, ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY on agent/fix-pnpm-legacy-scoped-name-quote). It is one occurrence, but it hits every pnpm 6–11 leg in both install-proof and the CI e2e matrix, and each of those runs this fixture install against the live registry.

Root cause

corepack() in e2e_redirect_pnpm_build.rs adds --fetch-retries=0 --fetch-retry-mintimeout=100 --fetch-retry-maxtimeout=500 to every install on pnpm 6–11. The clamp is there so the negative legs fail fast against the dead 127.0.0.1:1 registry and the tampered wiremock tarball. But it also applies to the one install that reaches registry.npmjs.org: the fixture setup in redirect_scanned_pnpm_project. With pnpm's own retry ladder switched off there, one connection reset fails a required leg. pnpm ≤5 and ≥12 never get the clamp, which matches 7.0.0 being the leg that failed.

Fix

Split the helper. corepack_with_retries(.., registry_retries: true) skips the clamp, and only the fixture install calls it. corepack() keeps the clamp unchanged for every other install: warm, clean, fresh dead-registry, tamper, ordinary and workspace. Their timing and assertions are the same as before. This adds no retry of its own; it just stops disabling pnpm's built-in one (2 retries, 10 s / 60 s backoff). A sustained registry outage still fails the leg.

Proof

• Reproduced the CI signature locally with a loopback registry that sends a TCP RST on the first /left-pad metadata request (socket.resetAndDestroy()), then serves [email protected]. Tested with pnpm 8.15.9, which is in the clamped 6–11 range. pnpm 7.0.0 doesn't run on the sandbox's Node 22.
  • With the clamp flags: 5/5 fail with ERR_PNPM_META_FETCH_FAIL ... failed, reason: read ECONNRESET, the exact CI error.
  • Without the flags (this PR's fixture path): 5/5 pass, with pnpm logging one retry (~10 s).
• SOCKET_PATCH_PNPM_E2E_VERSION=8.15.9 SOCKET_PATCH_PNPM_E2E_REQUIRED=1 cargo test -p socket-patch-cli --test e2e_redirect_pnpm_build -- --include-ignored: pnpm_pinned_matrix_install_verify_revert_and_tamper and pnpm_pinned_matrix_workspace_peer_instances pass on a real pnpm 8.15.9 against the live registry, and so do all hermetic tests. The named pnpm7/9/10/11_* capstones fail by design under that env (they assert pnpm@N but the env pins one binary). CI never runs them this way.
• cargo clippy -p socket-patch-cli --test e2e_redirect_pnpm_build -- -D warnings is clean, and rustfmt --check passes on the touched file.

Coverage / where tests run

No test is removed, skipped or weakened. Every assertion is unchanged. Only the fixture-setup install's retry policy changes. The tests run in the same places as before: pnpm-compatibility install-proof and the CI e2e matrix.

🤖 Generated with Claude Code

https://claude.ai/code/session_014WB83GYtGMDG4p6d3excea

Generated by Claude Code

Generated by Claude Code