Vendored mode still writes and deletes through a symlinked .socket dir: the #664 guard checks .socket/vendor and below only, so rollback in one yarn berry project wipes another project's vendored tarball and ledger #887

[agent] Found by the scheduled Yarn Berry (2+) bug-hunt routine (ledger #305).

Summary

#666 (fixing #664) made every vendored write and revert refuse when .socket/vendor, .socket/vendor/<eco> or .socket/vendor/<eco>/<uuid> is a symlink (vendor_dir_symlink_unsupported). It doesn't check the level above: .socket itself. Two projects that share one .socket through a link (a/.socket -> ../sock, c/.socket -> ../sock) end up with the exact cross-project delete-through that #664 describes.

• scan --mode vendored in each project writes its <uuid>/ unit and vendor/state.json into the shared target, with exit 0 and no warning.
• rollback, vendor --revert or remove <purl> in project a deletes the shared left-pad-1.3.0.tgz, socket-patch.vendor.json and state.json. It exits 0 with success.
• Project c's package.json and yarn.lock still point at file:./.socket/vendor/npm/<uuid>/left-pad-1.3.0.tgz, so every fresh yarn install --immutable fails YN0001 ENOENT.
• c's vendor --check then exits 0 (success, discovered: 0), because the shared ledger it would check is gone too.

Control: the same layout with the link one level lower (b/.socket/vendor -> ../../vend) is refused correctly with vendor_dir_symlink_unsupported, and nothing is written.

Impact

• Silent data loss in a different project: its committed artifacts and ledger are deleted by an unwind that reports success.
• That project's CI (yarn install --immutable, cold or warm cache, since file: is read from disk) fails. The integrity check that should catch it (vendor --check) passes.
• The two projects also share one state.json, so each vendor run rewrites the other's ledger.

Repro (Linux, yarn 4.18.1, node-modules linker)

A local mock patch API serves a granted vendoring-service artifact (tarball plus yarn-berry-zip) for pkg:npm/left-pad@1.3.0. The yarnBerry10c0 is bootstrapped with a real yarn file: install.

mkdir -p r/sock && cd r
for p in a c; do
  mkdir $p && (cd $p
    echo "{\"name\":\"$p\",\"private\":true,\"dependencies\":{\"left-pad\":\"1.3.0\"}}" > package.json
    printf 'nodeLinker: node-modules\nenableGlobalCache: false\n' > .yarnrc.yml
    yarn install && ln -s ../sock .socket)
done
git init -q && git add -A && git commit -qm init
(cd a && socket-patch scan --mode vendored --json --yes --api-url $MOCK --api-token x --org org && yarn install)  # exit 0
(cd c && socket-patch scan --mode vendored --json --yes --api-url $MOCK --api-token x --org org && yarn install)  # exit 0
git add -A && git commit -qm vendored   # sock/vendor/{state.json,npm/<uuid>/left-pad-1.3.0.tgz,…}
(cd a && socket-patch rollback --json --yes)          # exit 0, success
git status --short   # D sock/vendor/npm/<uuid>/left-pad-1.3.0.tgz, D …/socket-patch.vendor.json, D sock/vendor/state.json
git add -A && git commit -qm rollback-a
git clone -q . ../fresh && cd ../fresh/c && yarn install --immutable
#   ➤ YN0001: │ Error: left-pad@file:./.socket/vendor/npm/<uuid>/left-pad-1.3.0.tgz::locator=c%40workspace%3A.: ENOENT …
cd ../../r/c && socket-patch vendor --check --json   # exit 0, status success, discovered 0

Expected vs actual

• Expected: the rule Fix vendored revert deleting through a symlinked vendor dir (#664) #666 introduced, quoted from the vendor_dir_symlink doc (crates/socket-patch-core/src/vendor/path.rs:80-86): "Vendor staging creates these dirs itself and never writes symlinks, so a linked level is never ours: its target may be another project's vendor store … Every vendor and revert dispatch refuses on this before touching anything." A linked .socket is the same situation one level up, so the run should refuse with vendor_dir_symlink_unsupported, as it does for a linked .socket/vendor. Separately, CLI_CONTRACT says vendor --check verifies every vendored artifact, so a project whose lock is wired to a missing artifact shouldn't pass.
• Actual: vendor and unwind both follow the .socket link. The unwind deletes the other project's unit and ledger with exit 0, and the other project's vendor --check passes.

OS × version

Tested on main 9c43dfc. First bad: not a regression in the usual sense. Before #666 nothing was guarded; #666 left this level out.

Suspect code

• crates/socket-patch-core/src/vendor/path.rs:93: vendor_dir_symlink starts its levels at VENDOR_DIR (.socket/vendor), so .socket (constants.rs:4, SOCKET_DIR) is never checked.
• crates/socket-patch-core/src/utils/socket_dir.rs:74 (remove_tree_and_prune) is the delete that follows the link, as in Vendored yarn classic writes and deletes through a symlinked .socket/vendor/npm dir, so rollback in one project deletes another project's vendored tarballs and breaks its frozen install #664.
• The root cause isn't yarn-specific. Per the triage on Vendored yarn classic writes and deletes through a symlinked .socket/vendor/npm dir, so rollback in one project deletes another project's vendored tarballs and breaks its frozen install #664, every vendored backend unwinds through remove_tree_and_prune, so other ecosystems probably share it. I've only shown it with yarn berry.

Related: #664 / #666 (the .socket/vendor[/<eco>[/<uuid>]] levels, fixed), #627 / #802 (symlinked lockfiles, fixed), #831 (vendor --check passing after the vendored artifacts disappear).