Root `scan --mode vendored` exits 1 forever and drops its in-run VEX when a nested independent npm project installs a patched package the root lock doesn't have (hosted mode only warns)
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 4/5
- 預估耗時
- 1-2 天
- 新手友好度
- 45/100
- Issue 類型
- 缺陷
- 描述清晰度
- 描述清楚
- 活躍度
- 活躍
- 技術堆疊
- nodejs, rust
- 領域
- build-system, cli
研究方向
Start in crates/socket-patch-cli/src/commands/scan/mod.rs around lines 1788-1796, where hosted and vendored scans skip judge_nested_roots, then compare with the redirect_npm_entry_not_found warning path. The vendor backend's hard vendor_lock_entry_not_found refusal is in crates/socket-patch-core/src/vendor/npm_lock.rs around lines 534-540. Done means a root vendored scan with an independent nested npm project exits 0, emits a warning naming the nested PATH, and still writes the in-run VEX.
由索引模型根據 Issue 內容生成。
描述
[agent] Found by the scheduled npm bug-hunt routine (ledger #302).
Summary
A repository root is an npm project. tools/x/ is a separate npm project, not a workspace member, with its own package-lock.json and node_modules. It depends on a package that has a patch and that the root doesn't depend on.
socket-patch scan --mode vendored from the root crawls tools/x/node_modules (documented in docs/ecosystems.md, "npm: which node_modules trees are crawled"), downloads the patch, and passes the package to the root package-lock.json vendor backend. The backend refuses with vendor_lock_entry_not_found, so the run ends partialFailure, exit 1. That happens on every run: nothing the user can do at the root clears it.
scan --mode hosted over the same tree skips the package with redirect_unconfirmed / redirect_npm_entry_not_found, and exits 0. The scan code says nested copies are out of scope for both modes: crates/socket-patch-cli/src/commands/scan/mod.rs:1789-1791 reads "Hosted and vendored scans only rewire this root's lockfiles".
The Bun routine found this first on Bun 1.3.x and npm 10 and handed it over (ledger #302 entry 20261014T042736Z-from-bun). This issue is the npm reproduction.
Impact
- CI is permanently red. A root
scan --mode vendoredin any repo with an independent nested npm project (examples/,docs/,tools/) exits 1 every time. The root's own packages are vendored correctly and then reported as already vendored. - No in-run VEX.
scan --mode vendored --vex out.vex.jsonexits 1 and writes no document, even afternpm cihas installed the root's patched bytes. The same shape in hosted mode writes the VEX and exits 0. A standalonesocket-patch vexfrom the root works (exit 0, attests the root's package), so the failure comes only from the scan treating the nested copy as a failure. - The remedy is wrong. It says "make sure the package is installed and locked (
npm install)". The package is installed and locked, intools/x. Runningnpm installat the root or intools/xchanges nothing. - The per-path form fails the same way.
scan --mode vendored . tools/xvendorstools/xcorrectly, but its.leg still crawlstools/x/node_modulesand fails, so the command exits 1. It stays red even aftertools/xis vendored and reinstalled with patched bytes.
Repro
A local mock of the org patch API serves free patches for [email protected] and [email protected]. It answers batch, by-package, view and patches/package with a real patched tarball. Every socket-patch command gets --api-url <mock> --api-token fake --org test-org.
mkdir -p r/tools/x && cd r && git init -q && echo node_modules/ > .gitignore
echo '{"name":"root","private":true,"dependencies":{"minimist":"1.2.5"}}' > package.json
echo '{"name":"x","private":true,"dependencies":{"left-pad":"1.3.0"}}' > tools/x/package.json
npm install && (cd tools/x && npm install)
socket-patch scan --mode vendored --json --yes # run 1: partialFailure, exit 1
socket-patch scan --mode vendored --json --yes # run 2: partialFailure, exit 1 (minimist already_vendored)
npm ci
socket-patch scan --mode vendored --yes --vex out.vex.json --vex-product pkg:npm/[email protected] # exit 1, no out.vex.json
socket-patch vex -O out.vex.json --product pkg:npm/[email protected] --offline # exit 0, attests minimist
# hosted control (fresh copy of the same tree)
socket-patch scan --mode hosted --json --yes --patch-server-url <mock> # success, exit 0
Vendored output (npm 10.9.4, main 37c8918):
status: partialFailure (exit 1)
downloaded pkg:npm/[email protected]
downloaded pkg:npm/[email protected]
failed pkg:npm/[email protected] vendor_lock_entry_not_found package-lock.json has no rewritable entry for [email protected] — make sure the package is installed and locked (`npm install`) before vendoring
applied pkg:npm/[email protected]
Hosted output for the same tree:
status: success (exit 0)
skipped pkg:npm/[email protected] redirect_unconfirmed no lockfile entry pinning it could be rewritten
applied pkg:npm/[email protected]
W redirect_npm_entry_not_found: no package-lock.json entry for [email protected]
Expected vs actual
- Expected. A hosted or vendored scan rewires only the scan root's lockfiles (scan/mod.rs:1789). A nested project is reached by passing its PATH (docs/configuration.md: "Each PATH in hosted or vendored mode is a project directory"). So a crawled copy that belongs to a nested project should get the same treatment as in hosted mode: a warning that names the nested project and the PATH to run, with no failed event and no effect on the exit code or the in-run VEX. CLI_CONTRACT.md's exit-code rules reserve
partialFailurefor packages the run should have patched and couldn't. - Actual. The run fails with exit 1 on every run, omits the in-run VEX, and gives a remedy (
npm install) that can't clear it.scan . tools/xis also red.
Matrix
| OS | npm / Node | socket-patch | Reproduces |
|---|---|---|---|
| Linux | 10.9.4 / Node 22.22 | main 37c8918 |
yes (×3, incl. --vex and . tools/x) |
| Linux | 12.2.0 / Node 22.22 | main 37c8918 |
yes (×2 runs) |
| Linux | 8.19.4 / Node 22.22 | main 37c8918 |
yes (×2 runs) |
| Linux | 10.9.4 / Node 22.22 | v5.0.1 (npm latest) |
yes |
| Linux | Bun 1.3.0 / 1.3.9 / 1.4.3 | bb73e2f |
yes (Bun routine) |
| macOS / Windows | — | — | untested (probe branches unavailable). The logic is OS-independent. |
First bad: pre-existing. It is in v5.0.1 already.
Suspect code
crates/socket-patch-cli/src/commands/scan/mod.rs:1788-1796: agent and report-only scans calljudge_nested_rootsto assign each crawled copy to its own project root (#554). Hosted and vendored scans skip it, so vendored hands every crawled purl to the root backend.crates/socket-patch-core/src/vendor/npm_lock.rs:534-540: an absent entry becomes the hardvendor_lock_entry_not_foundrefusal, where hosted's equivalent (redirect_npm_entry_not_found) is a warning plus a skip.
🤖 Generated with Claude Code
- 主要語言
- Rust
- 星號
- 8
- 分支
- 1
- 平均合併
- 17 小時 5 分鐘
- 30 天內合併 PR
- 557
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
SocketDev/socket-patch 的其他 Issue
-
agent:triaged bug bughunt pm:npm priority:p3 ux
難度 2/5 1-3 小時 新手友好度 75/100
SocketDev/socket-patch#1072 · 2 則留言 ·
維護者通常 1 天內回覆
-
agent:triaged bug bughunt pm:yarn-berry priority:p1
難度 2/5 1-3 小時 新手友好度 73/100
SocketDev/socket-patch#783 · 1 則留言 ·
維護者通常 1 天內回覆
-
Vendored cargo warns cargo_multi_version_old_cargo ("declares no rust-version") when the root package inherits rust-version from [workspace.package]可能已有人在做 關聯的 PR 仍在進行中或已合併。 未關閉agent:triaged bug bughunt pm:cargo priority:p2
難度 2/5 1-3 小時 新手友好度 84/100
SocketDev/socket-patch#651 · 3 則留言 ·
維護者通常 1 天內回覆
-
agent:triaged bug bughunt pm:bundler priority:p1
難度 4/5 3-5 天 新手友好度 35/100
SocketDev/socket-patch#1531 · 1 則留言 ·
維護者通常 1 天內回覆
-
VEX product detection fails on Poetry 2 projects that declare dynamic = ["version"] with the version in [tool.poetry], so scan --vex exits 1 after rewriting poetry.lock可能已有人在做 @mikolalysenko 今天認領。 未關閉agent:claimed agent:triaged bug bughunt pm:poetry priority:p1
難度 3/5 半天 新手友好度 25/100
SocketDev/socket-patch#1527 · 3 則留言 ·
維護者通常 1 天內回覆
查看 SocketDev/socket-patch 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 66/100
storytold/photocraft#5710 ·
維護者通常 1 天內回覆
-
Two tests fail on a Windows checkout: a CRLF parse in feature_walk_tests, an 8.3 TEMP path in libraries_tests可能已有人在做 @CamWight 今天認領。 未關閉
難度 2/5 1-3 小時 新手友好度 75/100
bherbruck/solvecraft#1186 · 1 則留言 ·
-
area: screenshot audit bug good first issue priority: P3 security severity: info type: correctness
難度 2/5 1-3 小時 新手友好度 70/100
pierruno-labs/prowl#31 ·
-
難度 2/5 1-3 小時 新手友好度 70/100
limitlessprojects/Go-Hybrid#50 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 70/100
維護者通常 1 天內回覆