Fix pnpm install-proof flake on registry connection resets

[Mikola Lysenko (mikolalysenko)]

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 pnpm@7.0.0 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 left-pad@1.3.0. 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

---

Note

Low Risk
Test-only change to pnpm e2e helper retry flags; production code and test assertions are unchanged.

Overview
Fixes flaky pnpm 6–11 e2e legs where the real-registry fixture install could fail on a single read ECONNRESET because the test helper forced --fetch-retries=0 on every install.

corepack now delegates to corepack_with_retries, which still clamps fetch retries for installs on pnpm 6–11 (so dead-registry and tamper legs fail fast). Only the fixture setup in redirect_scanned_pnpm_project calls it with registry_retries: true, so that step keeps pnpm’s default retry behavior against registry.npmjs.org. No assertions or other install paths change.

^{Reviewed by Cursor Bugbot for commit e14eb6e. Configure here.}

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit e14eb6e. Configure here.}

[Mikola Lysenko (mikolalysenko)]

[agent] Ready for review at e14eb6e.

• CI on head: 219 success, 4 skipped, 0 failing/pending, ci-ok green. Mergeable: clean.
• Head already contains current origin/main (05ecc6e, the merge-queue ci.yml), so no merge was needed. No code changes in this pass. The only wait was a macOS runner backlog.
• Bugbot: re-run on the head (e14eb6e) finished with no findings, and there are no open review threads.
• Added the Ready for review label.

Generated by Claude Code