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

[mikolalysenko]

[agent] Found by the scheduled uv bug-hunt routine (ledger #310).

Summary

When the patch API publishes a new patch uuid for a package that a uv project already has wired, re-running scan reports the upgrade but never applies it:

• Hosted (scan --mode hosted), on a uv project (pyproject.toml + uv.lock) and on a PEP 723 script lock: status: success, exit 0, updates: [{oldUuid: A, newUuid: B}], rollout.counts.upgrade: 1, but redirect.redirected: 0 and rewrittenFiles: []. The only signal is the warning redirect_uv_project_unsupported (or redirect_uv_script_unsupported): "pyproject.toml: Python project already declares a source for six; revert it before applying a different patch". The source it names is socket-patch's own hosted pin from the previous scan. pyproject.toml and uv.lock stay on uuid A. --dry-run previews the same thing.
• Vendored (scan --mode vendored), project and script lock: exit 1, partial_failure, pypi_uv_source_already_exists ("[tool.uv.sources] already routes six to a socket-patch vendored wheel; run socket-patch vendor --revert before re-vendoring"), or pypi_lock_source_already_exists for a script. .socket/vendor/pypi/<uuid A>/ stays wired.

On the same mock, a hosted requirements.txt project re-pins to uuid B correctly (rewrittenFiles: ["requirements.txt"]), so the hosted refusal is specific to the uv [tool.uv.sources] writer.

Impact

• A superseding patch (for example a fix for a broken patch, or one that covers more advisories) never reaches uv users in hosted mode. CI stays green: exit 0, success, and updates[] even claims the upgrade happened. The project keeps installing the old patched wheel, and if that artifact is ever withdrawn, every fresh uv sync 404s while scan keeps reporting success.
• Vendored mode fails loudly, but it tells the user to revert a wiring that socket-patch itself wrote, which contradicts the contract below.
• Workaround (verified): socket-patch rollback, then scan --mode hosted again. That re-pins to uuid B, and uv sync --locked installs the new patched bytes.

Repro (Linux, real uv, local mock patch API)

The mock answers POST /v0/orgs/acme/patches/{batch,package}, GET …/by-package/… and GET …/view/<uuid>, plus SOCKET_PYPI_JSON_API. It serves a deterministic patched six-1.16.0-py2.py3-none-any.whl under uuid A (…0001, SOCKET_PATCHED = 1). It's then switched to offer only uuid B (…0004, a different patched six.py, SOCKET_PATCHED = 2) for pkg:pypi/six@1.16.0, and the old artifact URL stays served.

cat > pyproject.toml <<'EOF'
[project]
name = "app"
version = "0.1.0"
requires-python = ">=3.9"
dependencies = ["six==1.16.0", "idna==3.7"]
EOF
uv lock && uv sync -p 3.11
SP="--api-url $M --api-token fake --org acme --patch-server-url $M"
socket-patch scan --mode hosted --json --yes $SP     # wires uuid A: success, redirected 1
# patch API now offers only uuid B for pkg:pypi/six@1.16.0
socket-patch scan --mode hosted --json --yes $SP
#  exit 0, status "success"
#  updates: [{"purl":"pkg:pypi/six@1.16.0","oldUuid":"…0001","newUuid":"…0004"}]
#  rollout.counts: {"new":0,"deferred":0,"upgrade":1,"already":0}
#  redirect: {"redirected":0,"rewrittenFiles":[],"warnings":[{"code":"redirect_uv_project_unsupported",
#             "detail":"pyproject.toml: Python project already declares a source for six; revert it before applying a different patch"}]}
grep -o 'aaaaaaaa-0000-4000-8000-00000000000[0-9]' pyproject.toml uv.lock   # still …0001 only
# vendored:
socket-patch scan --mode vendored --json --yes $SP --vendor-url $M   # uuid A vendored
# switch to uuid B
socket-patch scan --mode vendored --json --yes $SP --vendor-url $M
#  exit 1, partial_failure, failed: pypi_uv_source_already_exists

Expected vs actual

• Expected (crates/socket-patch-cli/CLI_CONTRACT.md, "Per-run limit on new patches", "Classification"): an UPGRADE row ("the selection supersedes the recorded uuid … or the recorded uuid is no longer offered") hands the writer "the selected uuid", and "updates[] lists exactly the UPGRADE rows the run acts on". For vendored mode, the scan --vendor paragraph says: "A package the ledger holds at an older patch uuid is still re-vendored automatically when discovery selects the newer patch (its old uuid dir is removed — vendor_stale_artifact_removed)".
• Actual: hosted lists the upgrade in updates[], then refuses it with a warning and exits 0 on the old uuid. Vendored refuses with exit 1.

Matrix (Linux)

uv	hosted project	hosted script lock	vendored project	vendored script lock
0.5.31	fail (exit 0, not re-pinned)	–	–	–
0.8.17	fail (×2, also --dry-run)	fail	fail (exit 1)	fail (exit 1, pypi_lock_source_already_exists)
0.12.23 (latest)	fail	–	fail (exit 1)	–
control: hosted requirements.txt (uv pip)	pass: re-pinned to uuid B

Main 045d7ec (CLI 4.0.0). The behaviour comes from the writer, not from uv, so it doesn't depend on the OS. Not bisected: the uuid check has been in same_hosted_artifact since it was added in #358.

Suspect code

• crates/socket-patch-core/src/utils/python_script.rs:64 (same_hosted_artifact) only accepts a different grant-token segment. A different patch uuid (current_path[grant_index + 1]) counts as a foreign source, so python_script.rs:181 returns "already declares a source … revert it before applying a different patch". A pin that is socket-patch's own hosted URL for the same name and version (on a recognised patch server) should be replaceable on an UPGRADE row.
• crates/socket-patch-core/src/vendor/pypi_uv.rs:372-381 (pypi_uv_source_already_exists) refuses an existing socket-patch vendored source instead of re-vendoring it to the new uuid.
• Related but separate: 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 (the same symptom in the Hatch lane, utils/hatch.rs:147).

Note: the vendored re-vendor also fails on a plain requirements.txt project (pypi_requirements_already_vendored, exit 1). That's outside uv, so it's been handed to the pip routine rather than folded into this issue.

[mikolalysenko]

[agent] Triaged as priority:p1 (uv / PyPI family). Not a duplicate: #650 is the same symptom in the Hatch lane, and #266 is Maven (different code path, not clustered). No open or merged PR covers it.

Shares root cause with #650: the PyPI pyproject source writers (same_hosted_artifact in utils/python_script.rs for uv, replacement in utils/hatch.rs for Hatch, and the vendored guards in vendor/pypi_uv.rs / vendor/pypi_hatch.rs) only accept an existing pin that is byte-identical or differs in the grant token, so socket-patch's own earlier wiring at an older patch uuid is refused as a user source. Will be fixed together.

---

Generated by Claude Code

[mikolalysenko]

[agent] Claiming this issue (with #650; shared root cause: PyPI pyproject source writers refuse socket-patch's own earlier wiring at an older patch uuid). Branch: agent/fix-pypi-own-pin-repin. Claim-ID: 2026-10-04T03:20:54Z-020a8f

---

Generated by Claude Code

[mikolalysenko]

[agent] Draft PR: #743 (slice 1: hosted re-pin for uv and Hatch; vendored re-vendor is a follow-up slice).

---

Generated by Claude Code

[mikolalysenko]

[agent] Re-triage from the uv bug-hunt routine (ledger #310): PR #743 (head d0d9102) fixes the hosted half on real uv. The vendored half is unchanged, as the PR says.

Harness: a local mock patch API serves six 1.16.0 under patch uuid …0001, then switches to …0004 with different patched bytes. Both artifact URLs stay live. Each cell runs a hosted scan, switches the uuid, runs a second hosted scan, then rm -rf .venv && uv sync --locked, uv lock --check and rollback.

Cell	main 045d7ec	PR #743
project, direct six==1.16.0 (uv 0.5.31 / 0.8.17 / 0.12.23)	exit 0, redirect_uv_project_unsupported, still on …0001	redirected: 1; pyproject and uv.lock on …0004; --locked installs the v2 bytes; lock --check ok; rollback byte-identical
transitive six (via python-dateutil), override-dependencies wiring (0.8.17 / 0.12.23)	same refusal (new lane, same root cause)	pass, same checks; rollback byte-identical (upstream_uv_override_removed)
PEP 723 script lock (0.5.31 / 0.8.17 / 0.12.23)	redirect_uv_script_unsupported	pass; uv run --frozen --script prints the v2 marker; rollback byte-identical
--dry-run of the upgrade (0.8.17 / 0.12.23)	–	writes nothing; updates[] lists old → new uuid
--max-new-patches 0, with the upgrade plus one new patch (0.8.17)	upgrade refused; new patch rollout_deferred	upgrade applied; new patch rollout_deferred (matches docs/configuration.md "upgrade existing patches only")
vex --output after the upgrade (0.8.17)	–	not_affected, citing …0004
control: pylock.toml lane (0.8.17)	already passes on main	–

Vendored re-vendor (pypi_uv_source_already_exists) was not re-tested here; it's the stated follow-up slice.

---

Generated by Claude Code