Composer vendored repair (and re-vendor) rebuilds a deleted uuid dir without its socket-patch.vendor.json marker, leaving git showing the marker as deleted
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
从 crates/socket-patch-core/src/vendor/composer_lock.rs:311-345 开始，并将重建行为与 crates/socket-patch-core/src/vendor/cargo.rs:928-940 进行比较。使用 composer_lock.rs 中的 test_wired_missing_copy_rebuilds_artifact_only 作为起始测试；当删除的 uuid 目录能够同时重建 artifact 及其 socket-patch.vendor.json marker 时，即表示完成。
由索引模型根据 Issue 内容生成。
描述
[agent] Found by the scheduled Composer bug-hunt routine (ledger #321).
Summary
When a vendored Composer unit's uuid dir (.socket/vendor/composer/<uuid>/) is missing, for example because a checkout lost it or someone deleted it, socket-patch repair and a re-run of vendor download the patched copy again. Neither writes back the unit's socket-patch.vendor.json marker. The rebuild then reports success, but git status shows the marker as deleted. Committing that "repair" leaves the vendored unit without the marker that CLI_CONTRACT.md says every unit carries. Later vendor and repair runs (already_vendored, success []) never put it back.
The Cargo backend handles the same rebuild path correctly: it restores the marker when it's missing (crates/socket-patch-core/src/vendor/cargo.rs:928-940, pinned by test_wired_deleted_uuid_dir_rebuild_restores_marker). The Composer artifact-only rebuild branch doesn't.
Impact
Low. The install itself is fine: composer install from the repaired tree installs the patched bytes, and vex never reads the marker. But the repair leaves the committed vendored unit incomplete. External tools that rely on the marker ("belt-and-braces for tools that have the tree but not the lockfile") lose it, and the repair diff a user is asked to commit contains a surprise deletion.
Repro (Linux, Composer 1.10.28 and 2.10.3, PHP 8.3, main 61cfb9b)
The patch service is a local mock: POST /v0/orgs/acme/patches/package returns a granted result with an sha512 SRI, and GET serves a single-top-dir dist zip of the patched package. A manifest plus blob is staged under .socket/ for pkg:composer/acme/[email protected], from an inline package repository with a file:// zip dist.
composer update -n # installs acme/tool 1.0.0
printf '/vendor/\n' > .gitignore
git init -q && git add -A && git commit -qm init
socket-patch vendor --json --cwd . --api-url http://127.0.0.1:8765 --api-token fake --org acme
git add -A && git commit -qm vendored
git ls-files .socket/vendor | grep vendor.json
# .socket/vendor/composer/4d5e6f7a-…/socket-patch.vendor.json <- committed
rm -rf .socket/vendor/composer/4d5e6f7a-8b9c-4a1b-8c2d-0123456789ab
socket-patch repair --cwd . --api-url http://127.0.0.1:8765 --api-token fake --org acme
# Redownloaded pkg:composer/acme/[email protected] (.socket/vendor/composer/4d5e6f7a-…/acme/[email protected])
# Repair complete.
git status --short
# D .socket/vendor/composer/4d5e6f7a-8b9c-4a1b-8c2d-0123456789ab/socket-patch.vendor.json
socket-patch vendor --json --cwd . … # -> already_vendored
socket-patch repair --json --cwd . … # -> success, events: []
git status --short # marker still deleted
A vendor re-run instead of repair takes the same path. The JSON shows rebuilt with reason: vendor_artifact_missing, redownloaded: true, and the marker is still missing afterwards.
Expected vs actual
- Expected: CLI_CONTRACT.md ("Each vendored unit also carries an informational
socket-patch.vendor.jsonmarker … next to the artifact").repair"redownload[s] missing/corrupt vendored artifacts". The doc comment onwrite_marker_or_warn(crates/socket-patch-core/src/vendor/state.rs:808-812) says "Every backend's fresh and rebuild paths report it through here". After the rebuild the unit should be complete again (copy + marker), as it is for Cargo. - Actual: only the copy under
<uuid>/acme/[email protected]/is recreated. The marker stays deleted for good.
Matrix
| OS | Composer | Reproduces |
|---|---|---|
| Linux | 1.10.28 (PHP 8.3) | yes |
| Linux | 2.10.3 (PHP 8.3) | yes (×2) |
| macOS / Windows | n/a | untested. The code path is pure Rust filesystem logic, independent of OS and Composer version. |
First bad version: not a regression. v4.0.0 behaves the same way (rebuilt, marker left deleted).
Suspect code
crates/socket-patch-core/src/vendor/composer_lock.rs:311-345: the "Wired but the committed copy is missing/stale: rebuild the ARTIFACT only" branch calls composer_service_copy and mirror_filters::heal_or_warn, then returns. It never calls write_marker_or_warn, which only runs on the fresh path (composer_lock.rs:437-439). Porting Cargo's "restore the marker only when it is missing" block (cargo.rs:928-940) into this branch should fix it. test_wired_missing_copy_rebuilds_artifact_only (composer_lock.rs:1643) could assert the marker as well.
No probe runs: this is OS-independent.
- 主要语言
- 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 天内回复
-
agent:claimed agent:triaged arch-audit bug pm:hatch priority:p1
难度 2/5 半天 新手友好度 88/100
SocketDev/socket-patch#613 · 3 条评论 ·
维护者通常 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: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 天内回复
查看 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 天内回复
-
component:sight
难度 2/5 1-3 小时 新手友好度 78/100
agentic-os-org/ANOLISA#4622 · 1 条评论 ·
维护者通常 1 天内回复