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
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
研究方向
閱讀 crates/socket-patch-cli/src/commands/vendor.rs 第 4071 行附近和 crates/socket-patch-cli/src/commands/vendored_backend/repair.rs 第 184 行附近的內容，比較警告與 repair 的拒絕。執行與 vendor 還原警告相關的現有測試。當警告不再建議無法修復 ledger 缺漏的操作，且該行為由測試涵蓋時，即為完成。
由索引模型根據 Issue 內容生成。
描述
[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 repairto 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 [email protected] and [email protected])
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,rollbackandscan --prunealready give ("restore .socket/vendor/state.json from version control, or restore the lockfile withgit checkout -- <lockfile>"), or arepairthat 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):
| command | exit | message |
|---|---|---|
vendor --revert |
0 | vendor_orphan_still_wired → "run socket-patch repair to re-adopt" (wrong) |
repair |
1 | "repair does not rebuild the ledger … restore state.json" |
rollback |
1 | "restore .socket/vendor/state.json from version control …" |
scan --mode vendored --prune |
1 | "restore .socket/vendor/state.json from version control" |
vendor --check |
1 | vendor_ledger_missing … "restore state.json" |
OS × version
| OS | npm | result |
|---|---|---|
| Linux | 10.9.4 (Node 22.22) | fail (x2) |
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(thevendor_orphan_still_wiredtext) vscrates/socket-patch-cli/src/commands/vendored_backend/repair.rs:184(repair's refusal).
- 主要語言
- Rust
- 星號
- 8
- 分支
- 0
- 平均合併
- 1 天 1 小時
- 30 天內合併 PR
- 257
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
SocketDev/socket-patch 的其他 Issue
-
agent:triaged bug bughunt pm:npm priority:p1
難度 2/5 1-3 小時 新手友好度 85/100
SocketDev/socket-patch#1127 · 1 則留言 ·
維護者通常 1 天內回覆
-
agent:triaged bug bughunt pm:bundler priority:p1
難度 2/5 1-3 小時 新手友好度 75/100
SocketDev/socket-patch#1125 · 1 則留言 ·
維護者通常 1 天內回覆
-
agent:triaged bug bughunt pm:pipenv priority:p1
難度 2/5 1 小時以內 新手友好度 85/100
SocketDev/socket-patch#1122 · 1 則留言 ·
維護者通常 1 天內回覆
-
agent:triaged arch-audit bug priority:p3
難度 2/5 1-3 小時 新手友好度 85/100
SocketDev/socket-patch#1062 · 1 則留言 ·
維護者通常 1 天內回覆
-
agent:triaged bug bughunt pm:bundler priority:p1
難度 2/5 1-3 小時 新手友好度 80/100
SocketDev/socket-patch#1056 · 1 則留言 ·
維護者通常 1 天內回覆
查看 SocketDev/socket-patch 的全部 Issue
相似的 Issue
-
enhancement user-priority/P2
難度 2/5 1-3 小時 新手友好度 65/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 65/100
-
難度 2/5 1-3 小時 新手友好度 85/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 75/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 84/100
containers/aardvark-dns#743 ·