uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105

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

Summary

In a uv project that hosted mode patched with patch A, and whose .venv was then synced from the hosted lock (so six.py holds A's patched bytes), scan --mode vendored / get --mode vendored fails once the API serves a superseding patch B for the same six@1.16.0:

skipped  package_not_installed  no installed package found on disk
Error: Cannot vendor pkg:pypi/six@1.16.0: no installed package found on disk
Vendored 0 packages; 1 not installed.

The run exits 1, and the hosted takeover never happens. --dry-run of the same command reports would_vendor / success with exit 0.

Six is installed. The installed bytes are the hosted patch A's, so they match neither of B's beforeHash / afterHash. From the code, the variant probe then drops the candidate, because superseded_install only recognises an older patch generation through the vendor ledger. A hosted pin at another uuid isn't considered, so the candidate falls through to the "not installed" bucket.

Impact

A user who has been on hosted mode can't move to vendored once a newer patch exists, unless they first delete or reinstall their venv from PyPI. The run exits 1 with a false diagnosis ("not installed"), and the dry run promises success. The project stays hosted on the older patch A, so nothing is lost; the migration and the upgrade are just blocked. It hits every common uv flow, because uv sync after a hosted scan always installs the hosted bytes.

Repro (Linux, uv 0.12.23)

Patch data came from a local mock patch server (the one used on this ledger's probe branches), with a single origin. Its batch query returns patch A (…0001, adds SOCKET_PATCHED = 1) until a flag file exists, and patch B (…0004, SOCKET_PATCHED = 2) afterwards. Both are for pkg:pypi/six@1.16.0 with the same beforeHash.

git init -q app && cd app
cat > pyproject.toml <<'P'
[project]
name = "app"
version = "0.1.0"
requires-python = ">=3.9"
dependencies = ["six==1.16.0", "attrs"]
P
uv lock --python 3.11 && uv sync --python 3.11
socket-patch scan --mode hosted --yes --json                 # exit 0 (patch A)
rm -rf .venv && uv sync --locked --python 3.11               # .venv now holds patch A's six.py
git add -A && git commit -qm hosted
# --- the API now serves superseding patch B for six@1.16.0 ---
socket-patch scan --mode vendored --dry-run --yes --json     # exit 0, status success, six: would_vendor
socket-patch scan --mode vendored --yes --json               # exit 1, partial_failure, package_not_installed
git status --short                                           # nothing changed; still hosted on A
socket-patch get pkg:pypi/six@1.16.0 --mode vendored --yes --json   # exit 1, same event
rm -rf .venv && socket-patch scan --mode vendored --yes --json      # exit 0: takeover + vendored B (control)

scan --json does list the upgrade (updates: [{oldUuid: …0001, newUuid: …0004}]), and then vendors nothing.

Expected vs actual

• Expected: CLI_CONTRACT.md "Takeover reconciliation": scan / get --mode vendored over a live hosted pin restores the upstream entry and vendors the selected patch. The vendored A → vendored B upgrade of the same package works (vendor_stale_artifact_removed), and so do vendored A → hosted B and hosted A → hosted B. Hosted A → vendored B should behave the same way, or at least refuse with an accurate code that the dry run predicts too (exit-code parity).
• Actual: exit 1 with package_not_installed ("no installed package found on disk") although six is installed, and the dry run says would_vendor / exit 0.

OS × version

All runs were on Linux. The cause is in candidate selection, with no OS-specific file handling, so I didn't run a macOS / Windows probe. Other PyPI lanes with an installed hosted copy (Poetry, PDM, Pipenv) may behave the same way. I only confirmed the uv project and the uv pip requirements lanes.

Bisect

Not bisected. The hosted → vendored takeover is v5 (main) behaviour; I tested main 77f305d.

Suspect code

• crates/socket-patch-cli/src/commands/vendor.rs:2864: the variant probe drops the candidate unless superseded_install says the install is an older generation.
• crates/socket-patch-cli/src/commands/vendor.rs:2345: superseded_install only consults the vendor ledger (entry.uuid != record.uuid). A live hosted pin at another uuid (hosted_pins, discovered at vendor.rs:2732) isn't treated as a superseded install, so the takeover at vendor.rs:2928 is never reached. plan_service_downloads (vendor.rs:2413) uses the same check.
• The dry-run preview doesn't predict this outcome.

No probe runs (Linux only).

Backlog review — 2026-10-08

Priority: P1 → P2. Upgrading a uv takeover fails while the old hosted patch remains present. A conditional upgrade failure, not patch loss.