NuGet crawler test crawls the host's ~/.nuget/packages and fails on dev machines

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#2,023 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
76/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
rust
Bereich
devtools, testing

Rechercherichtung

Lies crates/socket-patch-core/src/crawlers/nuget_crawler.rs, insbesondere den Test solution_roots_and_unrestored_projects_keep_the_walk und den NUGET_PACKAGES-Test nahe Zeile 1450; sieh dir crate::test_env::EnvGuard an, um das vorhandene Muster zur Isolierung der Umgebung zu prüfen. Führe den cargo test-Befehl aus dem Issue aus, um das Problem zu reproduzieren und die Korrektur zu überprüfen. Fertig ist die Arbeit, wenn beide Tests geschützte Umgebungseinstellungen verwenden und bestehen, ohne den NuGet-Paketordner des Hosts zu lesen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug pm:nuget

LLM Description written by Claude Code:claude-opus-5-5

Summary

crawlers::nuget_crawler::tests::solution_roots_and_unrestored_projects_keep_the_walk (crates/socket-patch-core/src/crawlers/nuget_crawler.rs:1978) is not hermetic. It crawls the real global packages folder of the machine running it, so it fails on any developer machine whose ~/.nuget/packages holds a package. It passes in CI only because the runners' NuGet cache is empty.

Repro

On main (7bde3ba5), on a machine with any package in ~/.nuget/packages:

cargo test --locked -p socket-patch-core --lib solution_roots_and_unrestored_projects_keep_the_walk

panicked at crates/socket-patch-core/src/crawlers/nuget_crawler.rs:1994:9:
  left: ["pkg:nuget/[email protected]", "pkg:nuget/[email protected]", "pkg:nuget/[email protected]", "pkg:nuget/[email protected]"]
 right: ["pkg:nuget/[email protected]", "pkg:nuget/[email protected]", "pkg:nuget/[email protected]"]

The extra purl comes from the host's ~/.nuget/packages/socketsecurity.socketpatch/3.3.0. The test fails every time on such a machine, and passes with an isolated home:

HOME=$(mktemp -d) CARGO_HOME=~/.cargo RUSTUP_HOME=~/.rustup \
  cargo test --locked -p socket-patch-core --lib solution_roots_and_unrestored_projects_keep_the_walk
# test result: ok. 1 passed

Root cause

In project mode, crawl_roots always adds the global packages folder NuGet would restore into as search root 3 (nuget_crawler.rs:626-630, via global_packages_folder → nuget_home(), which falls back to $DOTNET_CLI_HOME or ~/.nuget/packages). A solution root, or a project that hasn't been restored, has no restore scope (roots.scope is set only for DotnetRoot::Project), so every package in that folder is crawled.

The test builds its packages in a temp shared-cache named by packageFolders, but leaves NUGET_PACKAGES and DOTNET_CLI_HOME unset. Its expected list (every) therefore assumes the host's default folder is empty or missing.

Suggested fix

Run the crawl under the existing crate::test_env::EnvGuard, with NUGET_PACKAGES pointed at an empty directory inside the test's tempdir (and DOTNET_CLI_HOME cleared). That makes root 3 hermetic without changing the crawler.

The NUGET_PACKAGES test around nuget_crawler.rs:1450 sets and removes the variable with bare std::env::set_var/remove_var, outside the guard. It should move onto EnvGuard too, so a parallel crawl test can't observe the variable while it's set.

Note

The product behavior the test pins, where a solution-root or unrestored-project crawl includes every package in the user's global folder, is the unscoped "today's walk" that #427 / #1183 deliberately kept for those roots. This issue is only about the test's isolation.

Found while validating #2015.

Vorherrschende Sprache
Rust
Sterne
9
Forks
2
Ø Merge
19 Std. 55 Min.
Gemergte PRs (30 T.)
608

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus SocketDev/socket-patch

Alle Issues in SocketDev/socket-patch

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.