vendor --revert with a lost vendor ledger tells you to "run socket-patch repair to re-adopt them into the ledger", but repair refuses because it never rebuilds the ledger, so the advice loops and the vendored npm packages can't be reverted #1072

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

Summary

When .socket/vendor/state.json is lost (deleted, or dropped by a bad merge) while package-lock.json still wires the vendored tarballs, socket-patch vendor --revert keeps the artifacts, which is the correct fail-safe. It then warns vendor_orphan_still_wired with this remedy:

a project lockfile still points at .socket/vendor/npm/, which no ledger entry owns; the artifacts were kept (run socket-patch repair to re-adopt them into the ledger, then revert again)

repair can't do that. It exits 1 with:

Cannot repair vendored artifact … the vendor ledger (.socket/vendor/state.json) has no entry for it, and repair does not rebuild the ledger from lockfiles; restore state.json from version control …

After repair, vendor --revert prints the same warning again ("Reverted 0 vendored packages.", exit 0). Following the advice goes round in a loop, and the project stays vendored.

Impact

Low severity, but it's a dead end for a user who doesn't have state.json in version control. The fail-safe parts all hold: in every step below, a cold-cache npm ci still installs patched bytes, and no artifact is deleted. Only the remedy is wrong. It contradicts CLI_CONTRACT.md (repair: "redownload missing/corrupt vendored artifacts (never re-synthesizing a lost ledger)"). It's in the same family as #900 and #977 (a suggested remedy that is a no-op).

Repro (Linux, npm 10.9.4, local mock of the patch API serving free patches for left-pad@1.3.0 and ms@2.1.3)

mkdir p && cd p
echo '{"name":"p","version":"1.0.0","dependencies":{"left-pad":"1.3.0","ms":"2.1.3"}}' > package.json
npm install
socket-patch scan --mode vendored --yes $API      # exit 0, both vendored
rm .socket/vendor/state.json                         # ledger lost
socket-patch vendor --revert --yes $API
#  Warning: … which no ledger entry owns; the artifacts were kept (run `socket-patch repair` to re-adopt them into the ledger, then revert again)
#  Reverted 0 vendored packages.        exit 0
socket-patch repair --yes $API
#  Error: Cannot repair vendored artifact … repair does not rebuild the ledger from lockfiles …   exit 1
socket-patch vendor --revert --yes $API             # same warning again, exit 0

Expected vs actual

• Expected: a remedy that works here. Either the one repair, rollback and scan --prune already give ("restore .socket/vendor/state.json from version control, or restore the lockfile with git checkout -- <lockfile>"), or a repair that actually re-adopts the entry, as the warning promises.
• Actual: the warning points at repair, which by contract and by its own message refuses this exact state.

Every other command reports this state consistently (main 05ecc6e, run twice):

OS × version

macOS and Windows weren't probed. The message is built in shared CLI code, so it isn't OS-dependent, and probably not npm-specific either (sweep_orphan_vendor_dirs is ecosystem-generic). Not bisected.

Suspect code

• crates/socket-patch-cli/src/commands/vendor.rs:4071 (the vendor_orphan_still_wired text) vs crates/socket-patch-cli/src/commands/vendored_backend/repair.rs:184 (repair's refusal).

Backlog review — 2026-10-08

Priority: P1 → P3. Missing-ledger recovery advice loops, but artifacts are retained and fresh installs remain patched. The report explicitly says only the remedy is wrong.