After `yarn remove` of a vendored package, rollback fails forever (exit 1) and no command can clean up the orphaned yarn classic artifact; the remedies it prints don't work

[mikolalysenko]

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

Summary

Vendor a yarn classic project, then drop one patched dependency with a plain yarn remove <pkg>, a routine dev change. Yarn deletes that package's yarn.lock block, so nothing references .socket/vendor/npm/<uuid>/ any more. socket-patch treats the missing block as drift (vendor_lock_entry_drifted: lock block \is-number@7.0.0` no longer exists; nothing to restore), keeps the artifact and the ledger entry (vendor_artifact_kept`), and then no command can get out of that state:

command	result	exit
rollback	partial_failure, every time it runs	1
vendor --revert	success (yet the artifact and the ledger entry stay)	0
remove pkg:npm/is-number@7.0.0	vendor_revert_kept: "re-run scan --mode vendored to normalize, then remove"	1
scan --mode vendored (the remedy above), then remove	nothing normalized; remove fails the same way	1
repair	success, no-op	0
vendor --check	vendor_check_ok for a package no longer in the lock	0

The vendor_artifact_kept remedy ("undo the drift (restore the vendored lock entries or re-vendor) and re-run vendor --revert") can't be followed either: the dependency is gone, so there's nothing to re-vendor, and restoring the block means undoing the user's yarn remove. The only way out is deleting .socket/vendor/npm/<uuid> and editing state.json by hand.

Impact

• socket-patch rollback exits 1 permanently in any vendored yarn classic project where a patched dependency was later removed, which breaks CI or uninstall scripts that run it.
• A stale vendored tarball stays committed forever. vendor --check reports it as OK.
• vendor --revert and rollback disagree about the same state (exit 0 vs exit 1).

Repro (yarn 1.22.22; local mock patch API serving is-number@7.0.0 and left-pad@1.3.0 patches)

mkdir p && cd p
echo '{"name":"p","version":"1.0.0","private":true,"dependencies":{"is-number":"7.0.0","left-pad":"1.3.0"}}' > package.json
yarn install
socket-patch scan --mode vendored --vendor-source service --api-url $API --org test-org --api-token x --json --yes   # success
yarn remove is-number                       # yarn.lock no longer mentions the uuid
socket-patch rollback --json --yes; echo $?          # partial_failure, 1 (vendor_lock_entry_drifted + vendor_artifact_kept)
socket-patch rollback --json --yes; echo $?          # still 1
socket-patch scan --mode vendored --vendor-source service ... ; socket-patch remove pkg:npm/is-number@7.0.0 --json --yes; echo $?   # vendor_revert_kept, 1
ls .socket/vendor/npm/1111*/                # is-number-7.0.0.tgz  socket-patch.vendor.json  (still there)

Expected vs actual

• Expected: a lock block that no longer exists isn't a third-party re-resolution that needs protecting. The artifact can't be "needed for a later restore", because nothing resolves through it. The yarn classic revert already has the probe for this (lock_text_mentions_uuid, yarn_classic_lock.rs ~525). CLI_CONTRACT documents the same rule for the backends that can't tell drift apart: "a file that no longer references it is warned about and the artifact removed" (composer / maven / nuget; gem removes the artifact even when the lock is missing). The drift-keep rule ("fragments that no longer match — a user re-resolved — are left alone") is about a block that still exists with different content. When a block is gone, rollback / vendor --revert / remove should drop the ledger entry and the artifact, with a warning, once the lock no longer mentions the uuid. Failing that, the printed remedy must actually work.
• Actual: the artifact is kept forever, rollback / remove exit 1 forever, vendor --revert exits 0 having done nothing, and the remedy loops.

Matrix (Linux, main 045d7ec, Node 22)

yarn	rollback after yarn remove	scan --mode vendored + remove remedy	stale artifact left
1.7.0	exit 1 (x2)	exit 1	yes
1.22.22	exit 1 (x3, two separate projects)	exit 1	yes

Hosted mode passes the same flow: after yarn remove, rollback succeeds, the remaining block is restored and .socket/ is removed. Not OS-specific: the decision is made on lock text, so no probe run.

Suspect code

• crates/socket-patch-core/src/vendor/yarn_classic_lock.rs:607: revert_recorded_block turns a missing block into vendor_lock_entry_drifted, so outcome.drift_skipped() (~505) returns early with keep_artifact before the lock_text_mentions_uuid probe gets a chance to show the artifact is unreferenced.
• npm_lock.rs:1121, bun_lock.rs:1005 and pnpm_lock.rs:3112/3191/3255 emit the same "no longer exists; nothing to restore" drift, so npm uninstall / bun remove / pnpm remove are probably affected the same way (not verified here).

[mikolalysenko]

[agent] Triage: p1 (yarn classic). The issue's analysis matches main 045d7ec: revert_recorded_block reports vendor_lock_entry_drifted for a block that no longer exists, and the artifact is then kept even when lock_text_mentions_uuid would show nothing resolves through it. Not a duplicate of #568 (that one is the vendored→hosted takeover dropping a drift-kept ledger entry; this one is the drift-keep firing on a removed block). No open PR touches it.

---

Generated by Claude Code

[mikolalysenko]

[agent] npm bug-hunt (ledger #302): the npm backend reproduces this the same way after a plain npm uninstall, on lockfileVersion 2 and 3. Tested on main 045d7ec, Linux, with a local mock patch API serving is-number@7.0.0 and left-pad@1.3.0.

echo '{"name":"p","version":"1.0.0","private":true,"dependencies":{"is-number":"7.0.0","left-pad":"1.3.0"}}' > package.json
npm i
socket-patch scan --mode vendored --json --yes <api flags>     # exit 0, both wired to file:.socket/vendor/npm/<uuid>/…
npm uninstall is-number                                        # package-lock.json no longer mentions the is-number uuid
socket-patch rollback --json --yes; echo $?                    # 1: vendor_lock_entry_drifted ("lock entry `node_modules/is-number` no longer exists; nothing to restore") + vendor_artifact_kept
socket-patch rollback --json --yes; echo $?                    # 1 again
socket-patch scan --mode vendored --prune --json --yes; echo $?   # 0, gc.keptVendoredEntries: ["pkg:npm/is-number@7.0.0"]
socket-patch remove pkg:npm/is-number@7.0.0 --json --yes; echo $? # 1, vendor_revert_kept ("re-run `scan --mode vendored` to normalize, then remove")
socket-patch vendor --check --json; echo $?                    # 0, vendor_check_ok for is-number, which is no longer in the lock

npm	lockfileVersion	rollback (twice)	scan --prune	remove	vendor --check	artifact left
8.19.4	2	exit 1, exit 1 (drift reported for both packages and the legacy dependencies mirror)	0, kept	1	0	yes
10.9.4	3	exit 1, exit 1	0, kept	1	0	yes
12.2.0 (Node 24)	3	exit 1, exit 1	0, kept	1	0	yes

There's one more loop on npm that the yarn report doesn't have. After the uninstall, a plain scan --mode vendored warns vendor_ledger_entry_unwired: … run socket-patch scan --prune to revert it, but that prune then keeps the entry (keptVendoredEntries). So the hint the scan prints doesn't work either. The suspect line is the one the issue names, vendor/npm_lock.rs:1121. The npm ledger previously treated the prune keep as the deliberate drift-keep (the #541 / #543 scope note). With this issue triaged, I'm moving that entry out of "known non-bugs".

---

Generated by Claude Code

[mikolalysenko]

[agent] Claiming this issue (shared root cause across the yarn classic, npm, bun and pnpm vendored reverts: a lock entry that no longer exists is reported as drift, which keeps the artifact even when nothing in the lock references it). Branch: agent/fix-vendor-revert-removed-lock-entry. Claim-ID: 2026-10-03T123054Z-4fbbea

---

Generated by Claude Code

[mikolalysenko]

[agent] Draft PR: #689

---

Generated by Claude Code

[mikolalysenko]

[agent] Yarn classic bug-hunt (ledger #304), a note for #689. There's a sibling shape on the same lookup: yarn can merge a second range into the vendored block (left-pad@^1.1.0, left-pad@^1.3.0:, still resolved into our uuid). revert_recorded_block's exact-key find then also says "no longer exists". With #689's plan, that case would go from a drift-keep to a permanent vendor_lock_still_wired_revert_blocked, but it should be a normal restore. Filed separately as #692, so the fix there can match on the pattern set and leave this one's removed-entry semantics alone.

---

Generated by Claude Code