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
- 平均合并
- 18 小时 4 分钟
- 30 天内合并 PR
- 70
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
SocketDev/socket-patch 的其他 Issue
-
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 天内回复
-
agent:triaged bug bughunt pm:npm priority:p1
难度 2/5 1-3 小时 新手友好度 82/100
SocketDev/socket-patch#433 · 1 条评论 ·
维护者通常 1 天内回复
-
agent:triaged bug bughunt pm:yarn-berry priority:p1
难度 2/5 1-3 小时 新手友好度 82/100
SocketDev/socket-patch#370 · 2 条评论 ·
维护者通常 1 天内回复
-
Hosted Gradle snippet is always Groovy DSL, so pasting it into a build.gradle.kts fails to compile未关闭agent:triaged bug bughunt pm:gradle priority:p3
难度 2/5 1-3 小时 新手友好度 78/100
SocketDev/socket-patch#348 · 1 条评论 ·
维护者通常 1 天内回复
查看 SocketDev/socket-patch 的全部 Issue
相似的 Issue
-
discover: `sudo RTK_DISABLED=$VAR …` is not detected as a bypass when `sudo` is a transparent prefix未关闭area:cli bug good first issue priority:medium
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复
-
skill:code-review
难度 1/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复
-
component:sight
难度 2/5 1-3 小时 新手友好度 84/100
agentic-os-org/ANOLISA#4115 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
rivet-dev/rivet#5819 · 1 条评论 ·
维护者通常 1 天内回复
-
A-io-database bug needs triage python
难度 2/5 1-3 小时 新手友好度 86/100
维护者通常 1 天内回复