Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Cerrado Apto para principiantes
  • ¿Algo no está bien?
#1,127 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Ya se ha fusionado un pull request relacionado.

  • #1338 de @mikolalysenko — fusionado

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
85/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
rust
Área
cli

Línea de trabajo

La causa raíz está en crates/socket-patch-cli/src/commands/scan/mod.rs, alrededor de las líneas 2673 y 2688, donde el retorno anticipado cuando all_packages_with_patches está vacío omite el GC de los paquetes vendor. Modifica el flujo de control para ejecutar el GC de los paquetes vendor en este caso, siguiendo el comportamiento de la ruta --json. Ejecuta la suite de pruebas de scan existente para verificar que la corrección resuelve la discrepancia entre la salida para humanos y la salida JSON.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Rust
Estrellas
8
Forks
1
Merge medio
16 h 35 min
PR fusionados (30 d)
574

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de SocketDev/socket-patch

Todos los issues de SocketDev/socket-patch

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.