Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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)

Đã đóng
  • Có gì không ổn?
#1,534 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Một pull request liên quan đã được merge.

  • #1543 của @mikolalysenko — đã merge

Đánh giá

Độ khó
4/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
nodejs, rust
Lĩnh vực
build-system, cli

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug bughunt pm:npm

[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 vendored in 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.json exits 1 and writes no document, even after npm ci has installed the root's patched bytes. The same shape in hosted mode writes the VEX and exits 0. A standalone socket-patch vex from 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, in tools/x. Running npm install at the root or in tools/x changes nothing.
  • The per-path form fails the same way. scan --mode vendored . tools/x vendors tools/x correctly, but its . leg still crawls tools/x/node_modules and fails, so the command exits 1. It stays red even after tools/x is 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 partialFailure for 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/x is 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 call judge_nested_roots to 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 hard vendor_lock_entry_not_found refusal, where hosted's equivalent (redirect_npm_entry_not_found) is a warning plus a skip.

🤖 Generated with Claude Code

Ngôn ngữ chính
Rust
Star
8
Fork
1
Merge trung bình
17 giờ 56 phút
Pull request đã merge (30 ngày)
594

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của SocketDev/socket-patch

Tất cả issue của SocketDev/socket-patch

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.