Hosted pnpm rollback/remove restores pnpm-lock.yaml from npmjs's version document instead of the project's .npmrc registry, so a mirror project loses its tarball: URL (cold frozen install 404s) or is moved to npmjs #919

[agent] Found by the scheduled pnpm bug-hunt routine (ledger #303).

Summary

This is the pnpm side of #908 (yarn berry) and #521 (vlt). Draft PR #918 fixes the shared root cause only for berry and vlt. restore_pnpm_locks isn't in its plan.

When rollback / remove undo a hosted pin in pnpm-lock.yaml, restore_pnpm_locks gets the upstream dist from fetch_dists → UpstreamClient::npm_dist. That always reads the version document from SOCKET_NPM_REGISTRY, or https://registry.npmjs.org when it's unset. The project's .npmrc registry= is read (pnpm_tarball_policy), but only to decide whether the tarball: key is written. It never decides which registry the dist comes from. So on a project that installs from a private mirror, with SOCKET_NPM_REGISTRY unset (the normal case), there are two failure modes:

1. The mirror's dist.tarball is non-conventional (CDN/download paths, e.g. GitHub Packages …/download/…, or a mirror whose tarballs live on another path or host). pnpm wrote tarball: <mirror URL> into the lock. The restore sees npmjs's conventional URL, decides pnpm derives it, and writes a bare {integrity}. pnpm then derives <mirror>/left-pad/-/left-pad-1.3.0.tgz, and a cold pnpm install --frozen-lockfile fails with ERR_PNPM_FETCH_404.
2. lockfileIncludeTarballUrl / lockfile-include-tarball-url is on (a setting the file the installed pnpm reads; that's the policy path Hosted pnpm rollback drops the upstream tarball: URL from locks written with lockfileIncludeTarballUrl, so the restore isn't byte-exact #557 / Fix hosted restore dropping registry tarball URLs (#557, #817) #818 added). The restore writes npmjs's dist.tarball in place of the mirror's URL. The project silently moves from its mirror to the public registry. That breaks air-gapped or allow-listed CI, and the result isn't byte-exact.

Both commands exit 0 with status: success.

Impact

After a hosted rollback or remove, a project on a private mirror can't install on a clean CI cache (mode 1), or fetches from a registry it isn't configured for (mode 2). socket-patch reports success, and nothing tells users to set SOCKET_NPM_REGISTRY to their mirror. CLI_CONTRACT documents the variable only as the base the restore reads.

Repro (Linux, main 9c43dfc, real pnpm)

Three local HTTP servers: a patch-API mock (:18601, which also serves the hosted tarball); an npmjs stand-in (:18602) whose dist.tarball is conventional under its own base, like npmjs (the sandbox binary can't reach npmjs, so the stand-in plays SOCKET_NPM_REGISTRY's default); and the project's mirror (:18603). The mirror serves the real left-pad-1.3.0.tgz, either at the conventional path or (CDN style) only at /_t/left-pad/1.3.0.tgz, with dist.tarball set to match.

mkdir proj && cd proj
echo '{"name":"proj","version":"1.0.0","dependencies":{"left-pad":"1.3.0"}}' > package.json
printf 'registry=http://127.0.0.1:18603/\n' > .npmrc
# mode 2 only: printf 'lockfile-include-tarball-url=true\n' >> .npmrc   (pnpm 9/10)
#              or 'lockfileIncludeTarballUrl: true' in pnpm-workspace.yaml (pnpm 10/12)
pnpm install && cp pnpm-lock.yaml lock.orig
export SOCKET_PATCH_SERVER_URL=http://127.0.0.1:18601 SOCKET_NPM_REGISTRY=http://127.0.0.1:18602  # = "unset" (npmjs)
socket-patch scan --mode hosted --yes --api-url http://127.0.0.1:18601 --org test-org --api-token fake   # pins left-pad
socket-patch rollback --yes --json            # rc 0, success   (same with `remove <uuid>`)
diff lock.orig pnpm-lock.yaml
# mode 1 (CDN mirror):
# <     resolution: {integrity: sha512-XI5M…, tarball: http://127.0.0.1:18603/_t/left-pad/1.3.0.tgz}
# >     resolution: {integrity: sha512-XI5M…}
# mode 2 (conventional mirror + tarball URLs):
# <     resolution: {integrity: sha512-XI5M…, tarball: http://127.0.0.1:18603/left-pad/-/left-pad-1.3.0.tgz}
# >     resolution: {integrity: sha512-XI5M…, tarball: http://127.0.0.1:18602/left-pad/-/left-pad-1.3.0.tgz}
# copy the tree without node_modules, cold store + cache:
pnpm install --frozen-lockfile
# mode 1:  ERR_PNPM_FETCH_404  GET http://127.0.0.1:18603/left-pad/-/left-pad-1.3.0.tgz: Not Found - 404
# mode 2:  fetches from :18602 (npmjs) instead of the mirror; the stand-in serves no tarballs, so it 404s here

Control: the same steps with SOCKET_NPM_REGISTRY=http://127.0.0.1:18603 (the project's own mirror) give a byte-exact lock and a clean cold frozen install. Another control: a conventional mirror without tarball URLs is byte-exact even with SOCKET_NPM_REGISTRY unset.

Expected vs actual

• Expected: CLI_CONTRACT's upstream restore puts back "resolution + integrity … from the npm registry's version document" so that the lock is what pnpm would write. For pnpm that's the registry the project resolves against (.npmrc registry=, or @scope:registry= for scoped names). Rollback of a hosted pin should return the lock to its pre-pin bytes, as it already does for a conventional mirror and for npmjs projects.
• Actual: the dist always comes from npmjs (or SOCKET_NPM_REGISTRY). The mirror's tarball: is dropped (mode 1) or replaced with npmjs's (mode 2), and the commands exit 0.

OS × version

Not a regression. Before #818 the pnpm restore never wrote tarball: (#557), so release 4.0.0 drops the mirror URL the same way in mode 1.

Suspect code

• crates/socket-patch-core/src/patch/redirect/upstream/npm.rs:815: restore_pnpm_locks calls fetch_dists (→ npm.rs:38 ctx.client.npm_dist, the default registry only) before it reads the project's registry.
• npm.rs:765: pnpm_tarball_policy reads .npmrc registry, but uses it only in registry_derives_tarball (npm.rs:841-851), not for the lookup. Scoped @scope:registry= keys aren't read at all.
• Related: Hosted yarn berry rollback/remove still drops a custom registry's ::__archiveUrl= binding (#817 fix incomplete): the restore looks up dist.tarball on npmjs, not the project's npmRegistryServer, so cold installs 404 #908 / vlt hosted rollback and remove rewrite slot [3] to a synthesized /<name>/-/<leaf>-<ver>.tgz URL instead of the registry's dist.tarball, so the next cold vlt ci 404s #521 (same root cause, other lock formats; PR Fix npm-family restore ignoring project registry (#908, #521) #918), Hosted pnpm rollback/remove adds registry tarball: URLs the lock never had when lockfileIncludeTarballUrl sits in a settings file the installed pnpm ignores (workspace file on pnpm 9, .npmrc on pnpm 11/12) #902 (which settings file decides the tarball: policy).

No probe runs: the sandbox is Linux-only, and this path has no OS-specific branches.