Scope project-mode NuGet crawls to the restore's resolved packages (#427)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #427

Summary

A project-mode scan of a restored .NET project used to list every package in the shared NuGet packages folder (~/.nuget/packages, NUGET_PACKAGES, every packageFolders key). Agent mode then patched packages that other projects had left there, and VEX attested them. This PR turns the crawler into a locator for restored projects. When cwd holds a .csproj/.fsproj/.vbproj, and every project under cwd at any depth has a parsed obj/project.assets.json with libraries, the shared roots are no longer walked. They are looked up only for the union of those resolved libraries (type: "package").

Why (leverage)

• Issue #427 is the NuGet child of tracking issue #595, register row E05 (register). The living document covers it in Part 6, "Cache crawls are not project-scoped".
• B 1: Project-mode NuGet agent scan patches, and VEX attests, packages the project doesn't depend on (the crawler lists the whole ~/.nuget/packages) #427.
• U 1: sets the locator shape for the cargo, go, Maven (Maven hosted scan pins, and VEX attests, artifacts the project doesn't depend on (the crawler lists all of ~/.m2) #265) and Deno children.
• D: one project.assets.json parser (parse_project_assets) serves both packageFolders and libraries.
• S 3: measured below.
• R M: project-mode discovery changes on purpose, as Tracking: scope project-mode cache crawls to what the project resolves #595's acceptance criteria ask.

What changed (crawlers/nuget_crawler.rs only)

• package_roots builds the root list, plus an optional scope. get_nuget_package_paths (same output as before) and crawl_all both use it.
• is_dotnet_project became dotnet_root, which returns None, Marker (solution, packages.config or NuGet config) or Project. Only Project roots are scoped.
• parse_project_assets parses one assets file into packageFolders and libraries. It replaces parse_project_assets_package_folders.
• restore_scope walks the source tree and unions every project directory's libraries. It returns None if any project is uncovered.
• locate_libraries probes <root>/<id lowercased>/<version lowercased>/ with the same verify_nuget_package and path_safety::is_safe_name_version guards as find_by_purls. It emits the same rows the walk produced for those directories.

Deleted

• The whole-cache walk of the shared roots for a fully restored project.

Behavior

• Changed: a fully restored project no longer crawls packages from the shared roots that its restores did not resolve. "Fully restored" means a project file at cwd, and every project file under it has a parsed assets file with libraries. The resolved packages come out with the same name, version, purl and path as before, but in libraries order instead of readdir order.
• Unchanged:
  • --global / --global-prefix;
  • solution roots without a root project file;
  • any tree where some project at any depth has no assets file or an assets file without libraries;
  • any tree with a directory that can't be fully listed, or more than 10,000 directories;
  • the project-local packages/ folder, which is still walked in full;
  • get_nuget_package_paths and find_by_purls.
• Remaining for Tracking: scope project-mode cache crawls to what the project resolves #595's NuGet item: the packages.lock.json fallback, and the crawl_unscoped_cache warning. The warning needs CLI_CONTRACT.md, which open PRs change.

Test evidence

• New unit tests in nuget_crawler.rs:

  • restored_project_crawls_only_its_resolved_packages
  • located_rows_equal_the_walks_rows_for_resolved_packages
  • sub_project_restores_join_the_scope (a restored sub-project two levels down)
  • an_uncovered_sub_project_keeps_the_walk (review fix: an unrestored sub-project two levels down, and an assets file without libraries)
  • project_local_packages_folder_is_still_walked
  • solution_roots_and_unrestored_projects_keep_the_walk
  • global_prefix_crawl_is_not_scoped

• Red → green:

  • On main, the Project-mode NuGet agent scan patches, and VEX attests, packages the project doesn't depend on (the crawler lists the whole ~/.nuget/packages) #427 tests fail. For example, the Project-mode NuGet agent scan patches, and VEX attests, packages the project doesn't depend on (the crawler lists the whole ~/.nuget/packages) #427 test gets [newtonsoft.json@12.0.1, newtonsoft.json@13.0.3, serilog@3.1.1] where it expects [newtonsoft.json@13.0.3].
  • an_uncovered_sub_project_keeps_the_walk fails on a05d7fc, the head before the review fix.
  • All of them pass on 038042f.

• cargo clippy --workspace --all-features -- -D warnings is clean.

• cargo test -p socket-patch-core --lib: 5805 passed on a05d7fc. Its only 4 failures are the known root-only sandbox ones, which also fail on main:

  • copy_tree::relax_loop_must_not_traverse_symlinked_root
  • vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry
  • pypi_poetry::wire_write_failure_maps_error_and_leaves_lock_untouched
  • pypi_requirements::wire_failure_rolls_back_already_written_files

  On 038042f I re-ran only the 40 crawlers::nuget tests, and they pass.

• crawler_nuget_e2e: 28 passed. CLI e2e_nuget: 21 passed. The NuGet crawler oracle equivalence suite also passes: its trees have no libraries, so they keep the walk.

• Timing (release build; I used a throwaway bench and removed it before committing). The fixture is a 3,000-package shared folder and a project that resolves 20 of them:

  • main: 58.5 ms per crawl, 3,000 packages;
  • branch: 0.80 ms per crawl, 20 packages.

• No dotnet in the sandbox, so I didn't run a real restore. The fixtures follow the assets format: libraries keyed "<Id>/<Version>", with type: package|project.

Risk

Medium.

• The scope walk lists the source tree. It skips hidden, symlinked, bin, obj, packages and node_modules dirs, and gives up after 10,000 directories.
• Any project the walk finds without a parsed restore, including one with a relocated BaseIntermediateOutputPath, makes the crawl fall back to the whole-cache walk. So a package is dropped only when no project's restore resolves it.
• A project outside cwd that is referenced by path is covered too, because its packages appear in the referencing project's libraries.
• The wrappers (npm/, pypi/, gem/) need no change.

🤖 Generated with Claude Code

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 038042f. Configure here.}

[Mikola Lysenko (mikolalysenko)]

[agent] test (windows-latest, 1) failed on 038042f in vendor::lock_inventory::view::tests::a_read_set_notices_a_changed_file (view.rs:1182, assertion "a replacement"). This PR doesn't touch that code:

• The test came in with Decide whether a hosted patch is pinned through lockfile discovery alone #1058 and checks the lock-inventory read set, which has no NuGet crawler code.
• The same job passed on this PR's previous head a05d7fc, and it passes on main (16106b1, 3a54db9, 568214e).

Likely root cause (Windows only). On non-Unix, Stat::of uses the file's creation time as its identity. The test writes a.tmp and renames it over a.lock, with the same length and the same bytes. NTFS file-system tunnelling keeps the old creation time when a file is renamed over a recently deleted name. modified can also tie at timer resolution. When both happen, the fingerprint can't see the replacement, so the result depends on timing.

Proposed fix (outside this PR's scope). On non-Unix, record every read as racy, so unchanged() compares the bytes it read against the file's current bytes. That is the existing racy path. An alternative is the Windows volume serial plus file index, once windows_by_handle is stable. No fix PR exists yet.

I'm re-running the failed job once to confirm.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] The one re-run of test (windows-latest, 1) failed again on 038042f, but in a different test. lock_inventory::view::tests::a_read_set_notices_a_changed_file passed this time. The failure is now patch::apply_lock::tests::zero_timeout_does_not_sleep_before_held (apply_lock.rs:1106): "non-blocking acquire should not sleep, took 116.2534ms".

This one isn't this PR's either: that test checks wall-clock time for apply-lock acquisition, which this PR doesn't touch, and it passes on main and on this PR's earlier head a05d7fc. So the job has now failed two different timing-sensitive Windows tests in a row, both outside this diff.

Proposed fix (outside this PR's scope). Assert that the acquire never entered the backoff sleep, through a counter or failpoint, instead of comparing elapsed time against a bound. A 116 ms stall on a shared Windows runner doesn't show a sleep. The proposed fix for view.rs is in my earlier comment. No fix PR exists for either yet.

I've used this PR's one re-run, so I'm leaving CI as is. The PR stays watched. A maintainer can re-run the job, or it will re-run with the next push.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[final reviewer] ci-ok was red on 038042f4 from one Windows unit test, patch::apply_lock::tests::zero_timeout_does_not_sleep_before_held (test (windows-latest, 1), run 37862006667, attempt 2): the non-blocking acquire returned the right LockError::Held but took 116 ms against the test's 100 ms limit. That test is unchanged on main and this PR doesn't touch apply_lock.rs (its only file is crawlers/nuget_crawler.rs), so this isn't this PR's failure. The 100 ms limit equals the backoff sleep it guards against, which leaves no room on a busy Windows runner. That is a CI-reliability fix for the janitor, and no fix exists yet.

I merged main into the branch (now 5ea0f7a9, a merge commit only, so the approval on 038042f4 still covers the code) to get a fresh CI run. Locally the 40 nuget_crawler unit tests pass after the merge. Once ci-ok and clippy are green, the next final-review pass sends it to the merge queue.

---

Generated by Claude Code