Repository navigation
Vendored-reference scan never sees NuGet or Maven wiring, so the orphan sweep deletes a still-wired unit #832
Description
Activity
- addedbugSomething isn't workingSomething isn't workingarch-auditFiled by a scheduled architecture audit routine (see the architecture review discussion)Filed by a scheduled architecture audit routine (see the architecture review discussion)
on Oct 5, 2026 mikolalysenko commented
on Oct 5, 2026 CollaboratorAuthorMore actions[agent] Triaged as priority:p3 (NuGet/Maven). Not a duplicate, and no open PR covers it.
Generated by Claude Code
mikolalysenko commented
on Oct 6, 2026 CollaboratorAuthorMore actions[agent] Related: #958 is the same file-list gap for
hatch.toml. It is listed inregistry::VENDORED_WRITES_UNMARKEDbut has noVENDOREDrole, so the orphan sweep deletes a wheel that ahatch.tomlenvironment still names (executed twice on9c43dfc). If this fix makesscan_vendor_referencesreadwiring_paths(every file a vendored run writes) instead ofpaths_with(VENDORED), it closes #958's half too. Re-checked on9c43dfc: the file list and the uuid-directory grammar gap described above are unchanged.
Generated by Claude Code
mikolalysenko commented
on Oct 6, 2026 CollaboratorAuthorMore actions[agent] Shares root cause with #958:
scan_vendor_referencesreads onlyregistry::paths_with(VENDORED), not every file a vendored run writes (wiring_paths). Will be fixed together (this issue additionally needs the NuGet/Maven uuid-directory grammar).
Generated by Claude Code
mikolalysenko commented
on Oct 7, 2026 CollaboratorAuthorMore actions[agent] Claiming this issue for the architecture refactor routine (highest leverage: one registry notion of "a file a vendored run writes" plus one uuid-unit grammar closes #832 and #958 together and deletes
VENDORED_WRITES_UNMARKED). Branch: arch-refactor/832-vendored-reference-scan. Claim-ID: 2026-10-07T12:56:20Z-90d5b6
Generated by Claude Code
mikolalysenko commented
on Oct 7, 2026 CollaboratorAuthorMore actions- added 2 commits that reference this issue
on Oct 7, 2026
[agent] Filed by the scheduled architecture audit routine (ecosystems and formats). Register: discussion #560 register.
Kind: bug. Source: new finding, register E61 (related to the backend-trait tracking row E21).
Problem
scan_vendor_referencesis the one check that keeps a.socket/vendor/<eco>/<uuid>/directory with no ledger entry from being deleted while a project file still points at it. It is used by the orphan sweeps (vendor --revert, the vendored gc pass), byrepair(vendor_ledger_missing), byvendor(vendor_ledger_entry_missing) and by rollback. It recognizes NuGet and Maven wiring in neither of the two ways it would need to:The file list. It reads
registry::paths_with(VENDORED)(repair.rs#L100-L104).`` The threenuget.configspellings and `pom.xml` are `HOSTED | PROBE`, without `VENDORED` (`registry.rs#L123-L125`, `#L142`). Yet those are exactly the files the NuGet and Maven vendored backends rewire.The reference grammar. Even if the files were read, both backends point at the uuid directory, not at a leaf inside it:
<add key="…" value=".socket/vendor/nuget/<uuid>" />(nuget_feed.rs#L950);<url>file://${project.basedir}/.socket/vendor/maven/<uuid></url>(maven_repo.rs#L1644).parse_vendor_pathrequires a non-empty leaf after the uuid (path.rs#L102-L108), and the scanner's terminator set has no<(repair.rs#L73-L77),`` so…/maven/<uuid></url>doesn't parse either.Meanwhile
sweep_vendor_dirsdoes enumeratenuget/andmaven/(ECOSYSTEM_DIRS), andsweep_orphan_vendor_dirsdeletes every unrecorded unit the scan didn't report (vendor.rs#L294-L333). Its doc comment states the invariant this breaks: "Deleting such a dir would break the next install, so every candidate is checked against the wiring-bearing files first".Also dead: the
vendorstranded-reference gate matcheseco == "maven2"(vendor.rs#L2134-L2139), butparse_vendor_pathonly ever yieldsmaven.Proof by execution (a throwaway
#[tokio::test]incommands/vendor.rs, run twice on045d7ec, then removed). It uses an emptyVendorState, one artifact file in the uuid dir, and the backend's own wiring text:The npm control is kept as still wired; the NuGet and Maven units are deleted while
nuget.config/pom.xmlstill name them.Symptoms
None filed. When a NuGet or Maven ledger entry is missing (state.json lost, a partial commit, or a merge that drops a row: the case the sweep guards against for every other ecosystem):
vendor --revertand the vendored gc delete the feed or repository, and the nextdotnet restore/mvnfails with a missing source;repairreports nothing (novendor_ledger_missing);vendorre-vendors without thevendor_ledger_entry_missingrefusal.Impact: destructive, but it needs a missing ledger entry first. Small fix.
Proposed change
pom.xmltheVENDOREDrole (check every reader ofpaths_with(VENDORED)/has(VENDORED)first). The Maven reactor's module poms live below the root, so add them the waywiring_filesalready adds the dynamic sets (vlt importers, requirements includes), or from the ledger's recorded wiring files.parse_vendor_dir_ref(or an optional leaf inparse_vendor_path) that yields(eco, uuid)for.socket/vendor/<eco>/<uuid>terminated by",<or end of value, and add<to the scanner's terminators. Repair can fall back to the uuid dir as the path for these.eco == "maven2"arm.VendorBackendtrait) should own "which files carry my references and how they are spelled", so that this table can't drift from the writers again.Size and scope
formats/registry.rs,vendor/path.rs,commands/vendored_backend/repair.rs,commands/vendor.rs; under ~80 production lines. The Gradle tree (.socket/vendor/gradle/) is outsideECOSYSTEM_DIRSand out of scope. The registry role change must not widen hosted reads (HOSTEDis unchanged).Acceptance criteria
scan_vendor_referencesreports(nuget, uuid)for a vendorednuget.config(all three spellings) and(maven, uuid)for a vendored rootpom.xmland a reactor module pom.sweep_orphan_vendor_dirswith an empty ledger keeps such units instill_wired(regression test mirroringorphan_sweep_keeps_include_referenced_dir), and still removes them once the reference is gone.repairreportsvendor_ledger_missingfor a NuGet/Maven reference with no ledger entry.scan_ignores_non_vendor_socket_mentionsand the existing repair/orphan tests stay green, and the vendored NuGet/Maven e2e suites pass.Dependencies
None. It touches
nuget_feed.rsandmaven_repo.rsonly for tests. Coordinate with #597 (hosted NuGet) only if it changesregistry.rs.