Vendored→hosted takeover on yarn classic un-patches a vendored npm: alias copy when a direct copy is pinned, instead of retracting the takeover #1158

[agent] Found by the scheduled Yarn classic (1.x) bug-hunt routine (ledger #304).

Summary

Take a yarn 1.22.22 project that depends on left-pad@1.3.0 both directly and through an npm: alias ("lp": "npm:left-pad@1.3.0"). yarn 1.22.22 writes these as two lock blocks. scan --mode vendored wires both blocks to the vendored tarball, so both copies install patched.

Now run scan --mode hosted (or get <uuid> --mode hosted). The staged takeover from #1039 reverts both blocks. The hosted rewriter then pins only the direct block and skips the alias block with redirect_yarn_classic_alias_skipped. Because the purl was pinned once, the takeover is not retracted. It commits, deletes .socket/vendor/, and reports redirect_takeover_reverted_vendored ("the project is now fully hosted for this package"). The alias block goes back to registry.yarnpkg.com, so node_modules/lp installs unpatched. The exit code is 0 and the status is success.

The same project with only the alias dep is handled correctly: the takeover is retracted with redirect_yarn_classic_alias_skipped + redirect_takeover_kept_vendored, and the tree stays byte-identical. So the retract only triggers when the purl gets no pin at all, not when a copy the project had patched loses its patch.

Impact

A user moving from vendored to hosted silently loses a patch they already had. The aliased copy goes from patched to unpatched with exit 0. The only signal is the generic alias-skip warning, while the takeover warning says the package is "fully hosted". The in-run --vex then attests not_affected over that unpatched copy (that half is #1081).

Repro (Linux, yarn 1.22.22, local mock patch API as in tests/e2e_redirect_yarn_classic_build.rs)

mkdir app && cd app
echo '{"name":"app","version":"1.0.0","dependencies":{"left-pad":"1.3.0","lp":"npm:left-pad@1.3.0"}}' > package.json
yarn install                       # 1.22.22 writes `left-pad@1.3.0:` and `"lp@npm:left-pad@1.3.0":` blocks
socket-patch scan --mode vendored --yes --json   # both blocks -> file:./.socket/vendor/npm/<uuid>/left-pad-1.3.0.tgz
socket-patch scan --mode hosted   --yes --json   # exit 0, status success
grep -A2 '"lp@' yarn.lock          # resolved "https://registry.yarnpkg.com/left-pad/-/left-pad-1.3.0.tgz#5b8a…"
ls .socket                         # gone
# fresh checkout:
yarn install --frozen-lockfile
head -1 node_modules/left-pad/index.js   # /* SOCKET-PATCHED */
head -1 node_modules/lp/index.js         # unpatched upstream

redirect.warnings[] codes: redirect_yarn_classic_alias_skipped, redirect_yarn_classic_berry_migration_risk, redirect_takeover_reverted_vendored. patches[]: left-pad@1.3.0 pinned.

Expected vs actual

crates/socket-patch-cli/CLI_CONTRACT.md, Staged takeover (v5.0): a staged purl the rewrite does not pin is retracted, with the cause taken from "the rewriter warning that names the package". It ends: "Exit 0: the package stays vendored and patched, never unpatched in both modes." docs/ecosystems.md documents that a hosted alias copy "keeps the unpatched artifact". In a takeover, though, that copy was patched (vendored) before the run.

• Expected: when the hosted rewrite skips a copy that the vendored wiring being reverted had patched (here redirect_yarn_classic_alias_skipped on a block the vendored ledger wired), retract the purl. It stays vendored, byte-identical, with redirect_takeover_kept_vendored, as the alias-only shape already does. Failing that, at least don't announce redirect_takeover_reverted_vendored / "fully hosted".
• Actual: the takeover commits and the alias copy is un-patched.

Matrix

macOS / Windows weren't probed: the decision is platform-independent planner logic.

First bad version

Not a #1039 regression. v4.0.0 (npm @socketsecurity/socket-patch@4.0.0) does the same: it reverts both blocks, pins the direct one, and leaves the alias on the registry with redirect_takeover_reverted_vendored. #1039 added the retract path, but it doesn't cover a partial pin.

Suspect code

• crates/socket-patch-cli/src/commands/scan/hosted/takeover.rs:285 Takeover::unpinned treats a staged purl as pinned once any (purl, uuid) is confirmed. It doesn't check that every lock entry the reverted vendored ledger entry had wired got pinned again.
• crates/socket-patch-core/src/patch/redirect/mod.rs:3709 is where the classic rewriter records alias_skipped for the purl, the signal the takeover could use.

The npm-family takeover path is shared, so yarn berry (redirect_yarn_berry_alias_skipped) may show the same thing; that's for the yarn-berry routine to check.