Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Human `scan --mode vendored --prune` silently skips the vendored GC when no remaining package has a patch, so an `npm uninstall`ed vendored entry is never reverted (exit 0), while `--json` reverts it and `vendor --check` keeps pointing at that same command

クローズ 初心者向け
  • 何か問題がありますか？
#1,127 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

関連するプルリクエストがすでにマージされています。

  • #1338 @mikolalysenko による — マージ済み

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
85/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
rust
領域
cli

調査の方向性

原因は crates/socket-patch-cli/src/commands/scan/mod.rs の2673行目と2688行目付近にあります。ここでは、all_packages_with_patches が空の場合の早期リターンによって、vendored GC がスキップされています。この場合にも vendored GC が実行されるように制御フローを変更し、--json 経路の動作に合わせてください。既存の scan テストスイートを実行して、この修正によって人間向け出力と JSON 出力の不一致が解消されることを確認してください。

索引モデルが issue の本文から書いたものです。

説明

agent:triaged bug bughunt pm:npm priority:p2

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

Summary

You vendor a patched npm dependency, then remove it with npm uninstall. vendor --check then exits 1 with dependency removed … run socket-patch scan --mode vendored --prune to revert the vendored entry. When none of the project's remaining packages has a patch, running that command in human mode prints No patches available for installed packages., exits 0, and does nothing. The ledger entry and .socket/vendor/npm/<uuid>/ stay, and vendor --check still exits 1. The same command with --json does revert the entry (gc.revertedVendoredEntries: ["pkg:npm/[email protected]"]).

Impact

  • The documented cleanup command doesn't work in the most common case: you removed your only patched dependency, or the only one left is unpatched. vendor --check sends you to it, it exits 0, and vendor --check still fails. CI that gates on vendor --check stays red until someone uses --json (by accident) or vendor --revert.
  • Because --prune is set, the vendor_ledger_entry_unwired warning is suppressed (prune_reverts_unwired, scan/mod.rs:1843). The human run gives no hint that anything was left behind.
  • Human and --json output disagree about what the same command writes.

Repro (npm 10.9.4 / Node 22, also npm 12.2.0 / Node 24; local mock of the public patch proxy serving a free patch for [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            # exit 0, left-pad vendored
npm uninstall left-pad                        # ms has no patch
socket-patch vendor --check; echo $?          # "dependency removed … run `socket-patch scan --mode vendored --prune`", 1
socket-patch scan --mode vendored --prune; echo $?
#   Found 1 package (1 npm)
#   No patches available for installed packages.
#   0
ls .socket/vendor/npm                         # 11111111-… still there; state.json still has left-pad
socket-patch vendor --check; echo $?          # still 1
socket-patch scan --mode vendored --prune --json | jq .gc.revertedVendoredEntries
#   ["pkg:npm/[email protected]"]   ← JSON reverts it

Control: when a remaining package does have a patch (the mock also serves [email protected]), the human run prints GC: reverted 1 vendored entry and vendor --check goes green. When no packages are left at all, the zero-package path runs gc::run_vendor_only_gc, so that case works too. Only "packages found, none patched" is broken.

Expected vs actual

  • Expected (CLI_CONTRACT.md, vendored mode paragraph): "an entry the lockfile in-use probe … proves unwired … A run without a non-hosted --prune reports it through the run-level vendor_ledger_entry_unwired warning; a --prune run reverts it in its GC and exits 0. That GC runs even when the crawl found no packages". Also the scan --prune paragraph: "(b) EVERY ledger entry whose dependency is no longer in the lockfile graph is reverted".
  • Actual: human mode, packages found but no patches: no GC, no warning, exit 0. --json: GC runs and reverts the entry.

Matrix (Linux)

npm human --prune reverts --json --prune reverts runs
10.9.4 (Node 22.22) no yes ×3 (incl. a workspace member npm uninstall -w a)
12.2.0 (Node 24) no n/a (not re-run) ×1
10.9.4, a patched package remains yes yes ×1 (control)

This is not OS-specific: it comes from scan control flow, not from the filesystem, so I didn't push a probe branch. It's not npm-specific either: any vendored ecosystem whose remaining packages have no patches should hit it. v4.0.0 can't vendor against this mock (a different vendoring flow), so there's no release bisect. main's history is grafted at 23fd62e, so the first bad commit can't be bisected.

Suspect code (main e2d9633)

  • crates/socket-patch-cli/src/commands/scan/mod.rs:2688: if all_packages_with_patches.is_empty() { … return finish_human(0).await; }
  • crates/socket-patch-cli/src/commands/scan/mod.rs:2673: finish_human runs the GC only if prune && !vendor && !hosted, because the vendored arm "runs its own". On this early return the vendored arm never runs, so nothing does.
  • The JSON path runs gc_json (scan/mod.rs:2633) regardless, which is why --json works.
  • scan/mod.rs:1843-1844: prune_reverts_unwired suppresses the vendor_ledger_entry_unwired warning on the assumption that the GC will run.

Backlog review — 2026-10-08

Priority: P1 → P2. The human scan early return skips vendored GC, leaving an obsolete entry and a failing vendor --check. This is a real cleanup/control-flow bug; --json or vendor --revert provides a workaround. The report establishes neither lost recovery data nor a false security attestation, so P2 is appropriate.

主要言語
Rust
スター
8
フォーク
0
平均マージ
19時間 44分
マージ済み PR（30日）
450

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

SocketDev/socket-patch のほかの issue

SocketDev/socket-patch の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。