Hosted uv rollback, remove and vendored takeover always refuse locks written by uv 0.6.15–0.6.17, which spell the artifact field `upload_time` instead of `upload-time`

[mikolalysenko]

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

Summary

uv 0.6.15, 0.6.16 and 0.6.17 write lock revision = 2 with the artifact timestamp key spelled upload_time (underscore). uv 0.7.0 and later spell it upload-time, and uv 0.6.0–0.6.14 write no timestamp at all. The v5 upstream restore in patch/redirect/upstream/uv.rs accepts only upload-time as a sibling artifact field. On these locks every hosted unwind refuses with:

cannot restore pkg:pypi/six@1.16.0 to its upstream registry entry: uv.lock: sibling artifacts carry an unknown field `upload_time`; restore it from version control instead (`git checkout -- uv.lock`)

scan --mode hosted itself works on these locks (it wires the project, uv sync --locked installs the patched wheel, and vex attests). The patch can't be taken off again: rollback, remove and the hosted→vendored takeover all exit 1. Project locks and PEP 723 script locks are both affected. A pylock from uv pip compile on 0.6.17 uses the PEP 751 upload-time, and it rolls back byte-identically.

Impact

On a uv 0.6.15–0.6.17 project, a hosted patch can be applied but never unwound or migrated to vendored mode, apart from git checkout. A newer uv keeps the field as written until something re-locks, so a lock that 0.6.x wrote stays affected even after the user upgrades uv. docs/testing/uv-compatibility.md says lock revision 2 (0.6.15–0.8.3) is covered, and scripts/uv-vex-matrix.sh includes 0.6.17. CLI_CONTRACT's "Hosted unwind coverage" list of refusals (exclude-newer / no-binary / no-build, non-PyPI registries, [[distribution]]) doesn't include this case. This is a refusal that fires when it shouldn't.

Repro (Linux, real uv; mock patch API as in the bug-hunt harness)

pip install --target /tmp/uv0617 uv==0.6.17; UV="env PYTHONPATH=/tmp/uv0617 /tmp/uv0617/bin/uv"
mkdir app && cd app
printf '[project]\nname = "app"\nversion = "0.1.0"\nrequires-python = ">=3.9"\ndependencies = ["six==1.16.0", "idna==3.7"]\n' > pyproject.toml
$UV lock && $UV sync
grep -c upload_time uv.lock            # 4
cp pyproject.toml p.o; cp uv.lock l.o
socket-patch scan --mode hosted --yes --json ...   # exit 0, six wired
socket-patch rollback --yes --json ...             # exit 1: unknown field `upload_time`
socket-patch remove pkg:pypi/six@1.16.0 --yes ...  # exit 1: same
socket-patch scan --mode vendored --yes ...        # exit 1, redirect_revert_failed: same

The same steps with uv 0.7.22 restore byte-identically.

Expected vs actual

• Expected: the upstream restore re-derives the six entry in the sibling's shape, using whichever key spelling the sibling uses. CLI_CONTRACT says artifacts are re-derived "in the artifact shape a sibling registry package shows (which of size / upload-time / … this uv release records)". The result is a byte-identical pyproject.toml / uv.lock, as on 0.7.x and later.
• Actual: refused, exit 1, with the files still pointing at the hosted wheel.

Matrix (main 045d7ec)

uv	lock key	Linux	macOS	Windows
0.6.14 and earlier	(none)	pass	–	–
0.6.15	upload_time	fail (rollback, twice)	–	–
0.6.16	upload_time	fail (rollback, twice)	–	–
0.6.17	upload_time	fail (rollback, remove, takeover, script lock)	fail (all 4)	fail (all 4)
0.7.0 / 0.7.22 / 0.9.30 / 0.10.12 / 0.11.33 / 0.12.23	upload-time	pass	pass (0.7.22)	pass (0.7.22)

Probe run: https://github.com/SocketDev/socket-patch/actions/runs/37210059602

First bad

The unreleased v5 upstream restore. The known field check was added in de316b4 (#358). The released v4.0.0 predates the uv upstream restore.

Suspect code

• crates/socket-patch-core/src/patch/redirect/upstream/uv.rs:466: let known = ["url", "hash", "hashes", "size", "upload-time", "name"]; has no upload_time.
• uv.rs:402 / uv.rs:419 / uv.rs:520 read and render only upload-time. The renderer also needs to write the key in the sibling's spelling.

[mikolalysenko]

[agent] Triage: priority:p1 (uv / PyPI family). Confirmed on main 045d7ec: the sibling-shape allowlist at crates/socket-patch-core/src/patch/redirect/upstream/uv.rs:466 (["url", "hash", "hashes", "size", "upload-time", "name"]) has no upload_time, and the reader/renderer at uv.rs:402, :419 and :520 only handle the hyphenated key. Every unwind of a lock that uv 0.6.15–0.6.17 wrote is refused. It isn't a duplicate, and no open or merged PR covers it (#512 fixed a different pylock shape issue). I haven't clustered it: the other open uv unwind refusals (#767, #723) come from different guards.

---

Generated by Claude Code

[mikolalysenko]

[agent] Claiming this issue (shared root cause: the uv upstream restore models only the upload-time artifact key spelling). Branch: agent/fix-uv-upload-time-key-spelling. Claim-ID: 2026-10-04T15:28:13Z-359f3f

---

Generated by Claude Code

[mikolalysenko]

[agent] Draft fix PR: #789

---

Generated by Claude Code

[mikolalysenko]

[agent] Re-triage from the uv bug-hunt routine (ledger #310): I verified draft PR #789 (head 39254e9) against this issue on Linux, using the real uv binaries and the same mock harness as the original report.

uv	Cell	main 045d7ec	PR #789
0.6.17	project hosted rollback	exit 1, unknown field `upload_time`	exit 0, pyproject.toml + uv.lock byte-identical
0.6.17	project remove pkg:pypi/six@1.16.0	exit 1, same refusal	exit 0, byte-identical
0.6.17	hosted → vendored takeover	exit 1, nothing vendored	exit 0, six vendored (.socket/vendor/... in uv.lock)
0.6.17	PEP 723 script lock rollback	exit 1	exit 0, tool.py + tool.py.lock byte-identical
0.12.23	all four cells above (regression check, upload-time spelling)	pass	pass, byte-identical

The restored 0.6.17 lock keeps the upload_time spelling on the restored six entry (4 occurrences, as in the original), so uv sees no diff. Once this lands I'll re-check it on main and close the issue.

---

Generated by Claude Code