Fix vendored uv/Hatch re-vendor to a newer patch (#742, #650)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #742
Fixes #650

Summary

A uv project, a uv PEP 723 script lock (or pylock) and a Hatch project that
were vendored with one patch now move to a newer patch for the same package on
the next vendor / scan --mode vendored / get --mode vendored. Before
this, the run failed with exit 1 (pypi_uv_source_already_exists,
pypi_lock_source_already_exists or pypi_hatch_unsupported) and told the
user to revert wiring socket-patch had written itself. The project kept
installing the old patch.

#743 fixed the hosted half of both issues. This PR fixes the vendored
half, which is what keeps both issues open. #766 did the same for
requirements.txt, and #825 does it for Pipenv.

Root cause

The three vendored backends' pre-flight guards (check_target_guards in
vendor/pypi_uv.rs, load_python_locks in vendor/pypi_lock.rs, and
load → hatch::replacement in vendor/pypi_hatch.rs) accept only wiring
for the current patch uuid. They treat socket-patch's own
.socket/vendor/pypi/<older uuid>/ source as a foreign one. Nothing ever
unwound the older uuid's wiring, even though the CLI contract says "a package
the ledger holds at an older patch uuid is still re-vendored automatically".

Fix

All in crates/socket-patch-core/src/vendor/pypi.rs, shared by the three
flavors:

• supersede_or_refuse: when one of those guards refuses, check the vendor
  ledger. If it holds exactly one entry for the same name and version under
  another uuid, with this flavor and recorded wiring, and a project file still
  references that uuid dir, the plan becomes WiringPlan::Supersede.
  Otherwise the refusal stands unchanged.

  • Hatch reports its uv-installer and Hatch >=1.2 guards under the same
    pypi_hatch_unsupported code. For Hatch, pypi_hatch::preflight checks
    those guards before anything is unwound, so a refusal unrelated to the
    old wiring never touches the project.

• unwire_superseded, at wiring time after the new wheel is built:

  1. snapshots every file the old entry may write, through the
     group-commit-aware utils::fs readers. Wiring paths from the tamper-able
     ledger must be plain relative paths outside .socket/.
  2. replays the old entry's own revert with keep_artifact. The CLI already
     sweeps the old uuid dir (vendor_stale_artifact_removed) once the new
     ledger entry lands.
  3. requires that revert to succeed with no drift and no remaining reference
     to the old uuid dir.
  4. re-plans the flavor fresh over the restored pre-vendor files
     (fresh_pyproject_plan) and wires the new wheel through the normal path.

  The new entry therefore records the user's real pre-vendor originals, and
  vendor --revert restores them byte for byte.

• Any failure (drifted wiring, a fresh guard refusing, a wiring error) puts
  every snapshotted file back and sweeps the new wheel, so the tree is left as
  it was. In a vendor run those writes sit inside the group commit. Any file
  that can't be restored is named in the reported error, never dropped. With
  no ledger entry for the old uuid it still refuses before writing, because
  there would be no recorded original to restore.

docs/testing/hatch.md now notes the vendored re-vendor. CHANGELOG.md is
untouched (release-time only).

Also ported: 13f6eee is #878's Gradle digest routing. Main has been red on
production_digests_go_through_the_helpers since #865. The port becomes a
no-op once #878 lands.

Tests (red → green)

Issue	Test	Before fix	After
#742 (uv project, script lock), #650 (Hatch)	vendor::pypi::tests::pyproject_flavors_revendor_to_a_superseding_uuid (each flavor: re-vendor to uuid B, originals carried, no uuid A left, revert byte-exact)	FAIL (refused)	pass
#742, #650	tests/mode_migration_pypi.rs::pyproject_flavors_vendored_revendor_superseding_patch (real CLI: vendor A → vendor B → in-sync re-run → vendor --revert; vendor_stale_artifact_removed, ledger on B only)	FAIL pypi_uv_source_already_exists (exit 1)	pass
guard	pyproject_flavors_superseding_uuid_with_drifted_wiring_refuses (hand-edited wiring: refuses, files byte-identical, no uuid B dir)	pass (refused)	pass
guard	pyproject_flavors_superseding_uuid_without_ledger_refuses, uv_stale_uuid_vendor_refuses_through_orchestrator (no ledger entry: still refuses before writing)	pass	pass
Bugbot	hatch_unrelated_guard_refuses_superseding_patch_before_unwinding (CLI, installer guard set: files, ledger, artifact A unchanged, no uuid B dir)	n/a	pass
Bugbot	restore_snapshot_reports_unrestored_files_and_restores_the_rest	n/a	pass

Local checks:

• cargo clippy --workspace --all-features -- -D warnings: clean.
• The changed files are rustfmt-clean.
• cargo test --workspace --all-features --no-fail-fast: 10822 passed, 12
  failed. All 12 are chmod 0o555 permission-denial tests that can't fail when
  run as root, which this sandbox is (uid 0). The same 12 are noted on Fix uv/Hatch hosted re-pin to a newer patch (#742, #650) #743,
  and CI runs them as non-root.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SECNaPEKiAJVRwYMMVAcLx

---

Note

Medium Risk
Changes vendored wiring, ledger-driven revert, and atomic file restore on failure; behavior is heavily tested but mistakes could leave projects half-wired or restore incorrectly.

Overview
Vendored PyPI re-vendor when a newer patch supersedes the same release — uv projects, PEP 723 script locks, and Hatch no longer fail with pypi_*_already_exists / pypi_hatch_unsupported when the vendor ledger still records socket-patch’s own wiring at an older patch UUID.

When those flavor guards would refuse “foreign” wiring that is actually the tool’s prior vendored path, vendor/pypi.rs now detects a single superseded ledger entry, plans WiringPlan::Supersede, and at wiring time snapshots project files, replays the old entry’s revert (keep_artifact), re-plans fresh wiring, and wires the new UUID. Failures restore the snapshot and sweep the new wheel; Hatch runs pypi_hatch::preflight before any unwind so unrelated installer guards leave the tree untouched.

Tests and docs add CLI and core coverage for happy path, drift, missing ledger, Hatch guard-before-unwind, and snapshot restore errors; Hatch testing docs note vendored supersede behavior.

Minor refactor: Gradle/JVM/Maven SHA-1/SHA-256 hashing routes through utils::digest helpers (aligned with #878).

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

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] coverage failed on dc2fadc in utils::digest::tests::production_digests_go_through_the_helpers. That failure isn't from this PR: main has been red on it since #865, whose guard flags the inline digests #646 added in gradle_cache.rs, jvm_jar.rs and sidecars/maven.rs. I ported #878's fix in 13f6eee. It becomes a no-op once #878 lands.

---

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 run

---

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 efc6d91. Configure here.}

[Mikola Lysenko (mikolalysenko)]

[burn-down agent] Ready for review at head efc6d91.

• CI: all check runs green or skipped on efc6d91; no merge conflicts, 0 commits behind main.
• Bugbot: reviewed efc6d91, no new issues. The 2 findings on 13f6eee were already fixed and their threads resolved; no unresolved review threads.
• Reviewer focus: the vendored uv / script-lock / Hatch backends now re-vendor over socket-patch's own wiring at an older patch uuid instead of refusing it (uv projects never pick up a superseding patch: hosted re-scan lists the upgrade in updates[] but refuses its own earlier [tool.uv.sources] pin (exit 0, still on the old uuid), and vendored re-scan fails pypi_uv_source_already_exists #742, Hatch never picks up a superseding patch: re-scan refuses its own earlier wiring ("existing direct source must be reverted"), so hosted exits 0 still pinned to the old patch uuid #650). Check that third-party sources are still refused.
• Slack announcement not sent this run (no Slack send tool available); the next run will retry.

---

Generated by Claude Code