uv rollback, remove and vendor --revert leave an empty [tool.uv.sources] header behind when the project's sources are written as [tool.uv.sources.<name>] sub-tables #524

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

Summary

Some uv projects write their sources only as sub-tables ([tool.uv.sources.idna] with url = … beneath it) and have no [tool.uv.sources] header. On those projects, hosted scan and vendored scan add an explicit [tool.uv.sources] header that holds the new six = { … } entry. rollback, remove and vendor --revert then remove the entry but keep the header and a blank line. So after a full round trip, pyproject.toml isn't byte-identical to the original: two lines ([tool.uv.sources] and an empty line) are left over.

Impact

The impact is low. The table is empty, uv parses it, uv lock --locked still passes, uv.lock is restored byte for byte, and the install is unchanged. But the tree is left dirty after an unwind, and that breaks "rollback and check for a clean git status" CI flows. It also breaks the restore contract. The residue is stable: a second scan → rollback cycle doesn't add more.

Repro (Linux, real uv 0.8.17 and 0.5.31, main 61cfb9b)

cat > pyproject.toml <<'EOF'
[project]
name = "app"
version = "0.1.0"
requires-python = ">=3.9"
dependencies = ["six==1.16.0", "idna==3.7", "certifi==2024.2.2"]

[tool.uv.sources.idna]
url = "https://files.pythonhosted.org/packages/e5/3e/741d8c82801c347547f8a2a06aa57dbb1992be9e948df2ea0eda2c8b79e8/idna-3.7-py3-none-any.whl"
EOF
uv lock && uv sync && cp pyproject.toml pyproject.orig
socket-patch scan --mode hosted --yes $API      # adds "[tool.uv.sources]\nsix = { url = … }\n\n" above the sub-table
uv sync --locked                                 # six is patched; vex says not_affected (redirected)
socket-patch rollback --yes $API                 # exit 0, status success
diff pyproject.orig pyproject.toml
# > [tool.uv.sources]
# >

The same residue appears with socket-patch remove <uuid> after a hosted scan, and with scan --mode vendored followed by vendor --revert. The patch API was a local mock serving a free six 1.16.0 patch (SRI integrity, deterministic wheel), and SOCKET_PYPI_JSON_API pointed at a pass-through to pypi.org.

Spellings that come back byte-identical, checked alongside: [tool.uv] + sources.idna = {…} (dotted key), a root-level tool.uv.sources.idna = {…}, sources = { idna = {…} } (inline table), and no sources at all.

Expected vs actual

• Expected: CLI_CONTRACT.md, "Hosted unwind coverage" → "What a restore does": "only the hosted entries change and every other byte stays the file's own". The [tool.uv.sources] header is hosted-mode bytes, so it should go when its last hosted entry goes, the same way it already does when hosted mode created the whole table.
• Actual: the header and a blank line stay. Exit code 0, with no warning.

OS × version

The rewrite is a pure text and TOML edit on the CLI side, independent of OS or uv release; uv only has to accept the result. Not bisected: v5 is the first release with the upstream restore.

Suspect code

• crates/socket-patch-core/src/vendor/pypi_uv.rs:498-502: created_sources_table is false whenever tool.uv.sources exists, including when it's only implied by a [tool.uv.sources.<name>] sub-table. So the remove_table_if_empty(…, "[tool.uv.sources]") call at :887-890 never runs, even though toml_edit printed a new explicit header.
• crates/socket-patch-core/src/patch/redirect/upstream/uv.rs:1111-1128 (restore_metadata): it removes the key, but the sources table isn't empty (it still holds the idna sub-table), and the table stays explicit, so the header is printed. One possible fix is to mark the table implicit again when only sub-tables remain and it wasn't explicit before the scan.