GeezerVison

remove <uuid> and rollback <uuid> matched the vendor ledger and the
hosted pins by the raw identifier only, never by the manifest entries
the identifier selected. When the manifest recorded a superseding patch
B while the ledger still held the vendored generation A, `remove <B>`
dropped the manifest record and left A's vendoring wired, reporting
success (#999).

Ledgers::matching now also selects the vendored entries a matched
manifest key claims, and the new ledgers::hosted_pins_matching selects
the hosted pins wiring the same release as a matched manifest key.
remove and rollback both route through them; the duplicate pin matcher
in remove.rs and the inline loop in rollback.rs are deleted.

Un-ignores remove_by_uuid_reverts_vendoring_when_ledger_generation_is_older
and adds its rollback twin.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

A hosted re-pin to a superseding patch moved the pin but left the old
generation's wiring behind:

- cargo kept [registries.socket-patch-<old>] in the cargo config, and
  remove never swept it (#864);
- Go kept the old gopatch module's go.sum pair, so `go mod tidy -diff`
  failed after every patch update (#682);
- Maven treated an earlier `-socket.<hex8>` literal as a user mismatch
  and never re-pinned, and a rotated grant token left the stale
  repository URL in place (#266).

Add patch::redirect::generation, the shared owned-pin generation policy:
one live socket-owned pin per release, a re-pin replaces the previous
generation and drops the wiring only it used, and a restore sweeps
every unreferenced generation. The cargo, Go and Maven rewriters and
the cargo restore use it; cargo, Maven and NuGet pin names now come
from its single hosted_pin_name, and the upstream Maven restore reuses
the rewriter's repository lookup/removal instead of its own copy.

Adds an owned_pin_generation_matrix test module (cargo, Go new-uuid
and republish, Maven supersede and token rotation) asserting that no
file names the superseded generation and a re-run is a no-op. The Go
equivalence golden is re-blessed: its re-run cases feed the rewriter's
own output back in, which now carries no superseded sum lines.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

The `socket-patch-<uuid>` grammar now lives only in
patch::redirect::generation: PIN_NAME_PREFIX, hosted_pin_name and
pin_name_uuid (the exact parser moved there from redirect/mod.rs as
socket_patch_name_uuid_exact). vendor::cargo_config::SOCKET_REGISTRY_PREFIX
is deleted, and the hand-built names in vendor/nuget_feed.rs,
vex/discover/cargo.rs, vex/discover/maven.rs and upstream/maven.rs go
through the generation helpers.

The same-release predicate (canonical base equal, or composer
equivalent) had four copies: ledgers::same_release, same_package in
vex_sources.rs and in vex/discover/mod.rs, and the inline filter in
rollback::superseded_by_hosted. vex::discover::same_release is the one
left; the others are deleted and their call sites routed through it.

The generation module doc now says what is implemented: the Go and
Maven restores do not sweep residue an older CLI left, and vendored
NuGet uses the same socket-patch-<uuid> source key.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

A `<base>-socket.<hex8>` literal counted as an earlier hosted generation
whenever its base matched, so a vendored reactor / sbt pin (the same
suffix under a socket-patch-vendor-<uuid> repository) was silently
re-pinned when the vendor ledger was missing. It is now a prior
generation only when the pom declared a hosted socket-patch-<uuid>
repository whose uuid starts with that hex8; otherwise the
redirect_maven_dep_version_mismatch skip stays.

The trusted-checksums drop split a CRLF file one way for the check and
another for the filter, so superseded entries survived and every re-run
rewrote the file. The file is LF-normalized first and both use the same
line test.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

A leftover socket-patch-A block beside the live pin B is swept when B is
restored, and the emptied config is deleted (#864). A generation the
restore did not select that a manifest still pins keeps its block.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

`remove <uuid A>` and `rollback <uuid A>` of a manifest record that a
hosted scan superseded with patch B now unwind B's lockfile pin too (one
owned pin per release). CLI_CONTRACT says so for both commands, and that
the hosted restore can then refuse offline. The in-process test reuses
the #933 fixture and drives both commands by the superseded uuid.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

…fecycle

# Conflicts:
#	crates/socket-patch-cli/CLI_CONTRACT.md

This branch now removes a superseded generation's [registries.*] block on
re-pin (d548f08), but the cargo/cargo/supersede redirect fixture and the
VEX discovery golden still expected the old socket-patch-0000... block to
survive, so redirect_golden and committed_fixture_corpus_matches_golden
failed. Record the new config, the redirect_cargo_superseded_registry_removed
edit, and regenerate the discovery golden with SOCKET_PATCH_UPDATE_GOLDEN.

Co-Authored-By: Claude <[email protected]>

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

…fecycle

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

The Benchmarks job flagged maven/rescan at +9-11% wall and CPU on three
consecutive heads of this branch. The supersede work added two per-pom
lookups that each re-scanned the whole pom with the repository regex:
the hosted-generation set (one scan per named generation) and the
rotated-token URL refresh (one scan per patched dep, even on a no-op
rescan).

Read every <repository>'s id and url in one pass up front. The hosted
generations come from that index (an exact `socket-patch-<uuid>` id is
the same set the per-uuid lookup produced), and while the pom is still
unchanged the refresh is skipped unless the index shows exactly one
repository with that id whose url differs, which is exactly when
refresh_maven_repository_url would have rewritten it. Once the pom has
changed this run, the refresh runs as before.

Local compare against main (perf profile, 15 paired runs):
maven/rescan +3.8% -> +0.6%; maven/hosted unchanged (+1.7%).

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

The superseded-repository cleanup removed every socket-patch-<uuid>
repository whose uuid starts with the old suffix's eight hex digits. The
suffix carries only those eight digits, so another artifact's live
`-socket.<hex8>` pin from a different uuid with the same prefix lost its
repository and stopped resolving. Skip the removal while any
`-socket.<hex8>` literal remains in the pom, and pin it with a two-artifact
re-pin test.

Co-Authored-By: Claude <[email protected]>

cursor Bot left a comment

…fecycle

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

… pinned

The hex8-sharing guard skipped the whole superseded-version cleanup, so a
re-pin that kept another artifact's -socket.<hex8> literal also left the
abandoned generation's jar and pom entries in the trusted checksums file.
Those entries are keyed by the artifact's own GAV and cannot belong to the
twin pin, so only the repository removal is now guarded.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

Pick up #1093 so PR CI runs without the macOS legs.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>