Hosted rollback rewrites uv pylock.toml `upload-time` with milliseconds, so the restored file never matches what uv writes
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
研究方向
從 crates/socket-patch-core/src/patch/redirect/upstream/uv.rs 中第 394 行附近的 upload_time() 和第 424-433 行附近的 shape.datetime 分支開始。將 pylock.toml 的格式與同級的 lock 格式進行比較，然後重現 hosted scan 和 rollback 流程，並將還原的檔案與其原始檔案進行 diff。完成標準是 pylock 的 upload-time 值使用整秒精度，且 rollback 不留下任何多餘的 diff。
由索引模型根據 Issue 內容生成。
描述
[agent] Found by the scheduled uv bug-hunt routine (ledger #310).
Summary
After a hosted scan and then rollback (or remove), a uv-written PEP 751 pylock.toml doesn't come back as uv wrote it. The restored sdist / wheels entries carry upload-time with milliseconds (2021-05-05T14:18:17.237Z). uv writes pylock upload-time as a TOML datetime truncated to whole seconds (2021-05-05T14:18:17Z), and so do the lock's own untouched sibling entries. Every rolled-back pylock is left with a spurious diff that no uv command would produce.
The upstream restore formats upload-time with uv.lock's millisecond rule (upload_time() in crates/socket-patch-core/src/patch/redirect/upstream/uv.rs:394) for both lock kinds. For pylock it only switches the quoting (shape.datetime, :424-433), not the precision.
Impact
This is low severity: the restored file is valid and installs the pristine wheel (uv pip sync pylock.toml → original six.py). But "rollback" doesn't return the file to its pre-patch bytes. A repo that regenerates pylock.toml in CI (uv export --format pylock.toml) and checks git diff --exit-code fails after an otherwise clean rollback, and the leftover diff looks like a Socket edit that was never undone. The uv.lock and requirements.txt restores in the same run are byte-identical, so the gap is pylock-specific.
Repro (Linux)
Mock patch API as in #379 / #381, with --patch-server-url for the mock origin and the PyPI JSON API reachable.
SP="socket-patch --api-url http://127.0.0.1:18080 --api-token t --org test-org --patch-server-url http://127.0.0.1:18080"
mkdir p && cd p
printf '[project]\nname = "uvp"\nversion = "0.1.0"\nrequires-python = ">=3.9"\ndependencies = ["six==1.16.0", "idna==3.7"]\n' > pyproject.toml
uv lock && uv export --format pylock.toml -o pylock.toml
cp pylock.toml pylock.orig
$SP scan --mode hosted --json --yes # rewrittenFiles includes pylock.toml
$SP rollback --json --yes # success, hosted.reverted [pkg:pypi/[email protected]]
diff pylock.orig pylock.toml
# < sdist = { url = ".../six-1.16.0.tar.gz", upload-time = 2021-05-05T14:18:18Z, size = 34041, ... }
# > sdist = { url = ".../six-1.16.0.tar.gz", upload-time = 2021-05-05T14:18:18.379Z, size = 34041, ... }
# < wheels = [{ url = ".../six-1.16.0-py2.py3-none-any.whl", upload-time = 2021-05-05T14:18:17Z, ... }]
# > wheels = [{ url = ".../six-1.16.0-py2.py3-none-any.whl", upload-time = 2021-05-05T14:18:17.237Z, ... }]
The same diff appears when pylock.toml sits next to uv.lock and an exported requirements.txt (those two restore byte-identically). uv 0.8.17, uv 0.12.21, and uv pip compile --format pylock.toml all write upload-time = 2021-05-05T14:18:17Z for that wheel.
Expected vs actual
- Expected: CLI_CONTRACT.md, "Hosted unwind coverage": rollback restores each hosted pin "to its default upstream registry entry", with the artifact fields in the shape "the lock's other registry packages" show. Here the siblings show second precision, and uv only ever writes that precision in pylock files. The restored entry should be what uv would write, as it already is for
uv.lock. - Actual: millisecond
upload-timevalues in the restored pylock entry.
OS × uv matrix (main 2463257)
| OS | uv 0.8.17 | uv 0.12.21 |
|---|---|---|
| Linux | fail | fail (reproduced 2×) |
macOS and Windows weren't probed. The defect is in platform-independent string formatting.
First bad
2463257 (#277, v5 upstream restore). Release 4.0.0 restored pylock from a recorded fragment.
Suspect code
crates/socket-patch-core/src/patch/redirect/upstream/uv.rs:394 (upload_time, millisecond rule) and :424-433 (the shape.datetime branch, which should truncate to seconds for pylock, or follow the siblings' precision).
Related: #407 (a uv pip compile pylock can't be rolled back at all).
- 主要語言
- Rust
- 星號
- 8
- 分支
- 0
- 平均合併
- 15 小時 39 分鐘
- 30 天內合併 PR
- 104
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
SocketDev/socket-patch 的其他 Issue
-
agent:triaged bug bughunt pm:cargo priority:p2
難度 2/5 1-3 小時 新手友好度 84/100
SocketDev/socket-patch#651 · 1 則留言 ·
維護者通常 1 天內回覆
-
Vendored Hatch runs a `hatch` executable planted in the scanned project可能已有人在做 @mikolalysenko 於 1 天前認領。 未關閉agent:claimed agent:triaged arch-audit bug pm:hatch priority:p1
難度 2/5 半天 新手友好度 88/100
SocketDev/socket-patch#613 · 3 則留言 ·
維護者通常 1 天內回覆
-
Patch blob and diff downloads buffer the whole response body with no size cap可能已有人在做 @mikolalysenko 於 1 天前認領。 未關閉agent:claimed agent:triaged arch-audit bug priority:p3
難度 2/5 1-3 小時 新手友好度 84/100
SocketDev/socket-patch#571 · 5 則留言 ·
維護者通常 1 天內回覆
-
agent:triaged bug bughunt pm:composer priority:p2
難度 2/5 1-3 小時 新手友好度 90/100
SocketDev/socket-patch#515 · 1 則留言 ·
維護者通常 1 天內回覆
-
agent:triaged bug bughunt pm:npm priority:p1
難度 2/5 1-3 小時 新手友好度 82/100
SocketDev/socket-patch#464 · 1 則留言 ·
維護者通常 1 天內回覆
查看 SocketDev/socket-patch 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 92/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 72/100
rust-windowing/winit#4731 ·
維護者通常 2 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 1 天內回覆
-
area:cli bug priority:high
難度 2/5 1-3 小時 新手友好度 85/100
維護者通常 1 天內回覆
-
Anthropic streamed blocks without a content_block_stop are discarded可能已有人在做 @Frun1na 今天認領。 未關閉component:sight
難度 2/5 1-3 小時 新手友好度 78/100
agentic-os-org/ANOLISA#4622 · 1 則留言 ·
維護者通常 1 天內回覆