Go rollback and remove in a go.work member stay silent about a stale `go work vendor` modules.txt, so every workspace build fails with "inconsistent vendoring"
メンテナーはふだん 1 日以内に返信
関連するプルリクエストがすでにマージされています。
- #1767 @mikolalysenko による — マージ済み
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 15/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 領域
- build-system, cli
調査の方向性
Start in crates/socket-patch-core/src/vendor/go_consumer_sync.rs, where vendor_modules_txt_issues filters recorded replacements by socket_owned() around line 580, and compare with same_replacement, which already strips the member prefix for workspaces. Reproduce with the e2e_golang_build shape in tests/e2e_golang_build.rs using a use ./a member, then run rollback. Done means that warning fires and the workspace builds. Open PR #1767 already targets this, so coordinate with it first.
索引モデルが issue の本文から書いたものです。
説明
[agent] Found by the scheduled Go modules bug-hunt routine (ledger #317).
Summary
The #343 fix (#1357) warns go_vendor_modules_txt_out_of_sync when a committed vendor directory still records a socket-patch replacement that go.mod no longer has. In a workspace, this only works when the patched module is the go.work root (use .). For any other member (use ./a), go work vendor records the member's replace relative to the workspace root:
# example.com/upstream v1.0.0 => ./a/.socket/go-patches/example.com/[email protected]
detect_owner (crates/socket-patch-core/src/vendor/go_mod_edit.rs:88) only treats a target as socket-owned when it starts with ./.socket/go-patches/ or ./.socket/vendor/golang/. So this recorded line counts as user-authored, and the stale check in vendor_modules_txt_issues (crates/socket-patch-core/src/vendor/go_consumer_sync.rs:580, recorded.iter().filter(|r| r.socket_owned())) skips it.
The other direction already works: after apply, the "not recorded" warning fires, because same_replacement does a suffix match for workspaces.
Impact
After rollback or remove in a non-root member of a vendored workspace, both commands exit 0 with no warning, and apply --check says "No patches to check" (exit 0). But every workspace build (go build, go run, go test, which default to -mod=vendor when the workspace has vendor/modules.txt) now fails:
go: inconsistent vendoring in …/ws:
example.com/[email protected]: is marked as replaced in vendor/modules.txt, but not replaced in the workspace
The same rollback in a use . root module does warn, which is the documented behaviour.
Repro
Hermetic file GOPROXY, hand-staged .socket/manifest.json plus blob (the tests/e2e_golang_build.rs shape). Go 1.22+ (go work vendor).
# ws/go.work: go 1.22 \n use ./a
# ws/a/go.mod: module example.com/a; require example.com/upstream v1.0.0; main.go prints upstream.Greeting()
# ws/a/.socket/manifest.json + blob patching lib.go PRISTINE -> PATCHED
cd ws && go work vendor
(cd a && socket-patch apply) # warns go_vendor_modules_txt_out_of_sync (correct)
go work vendor && go run ./a # OUT: PATCHED
cd a && socket-patch rollback --json # status success, warnings: none <-- bug
socket-patch apply --check; echo $? # "No patches to check.", 0
cd .. && go run ./a # go: inconsistent vendoring … is marked as replaced in vendor/modules.txt, but not replaced in the workspace
socket-patch remove pkg:golang/example.com/[email protected] behaves the same way. Control: the same steps with use . and the module at the workspace root make rollback warn go_vendor_modules_txt_out_of_sync.
Expected vs actual
- Expected, per docs/ecosystems.md (warning table,
go_vendor_modules_txt_out_of_sync): the warning fires for "a committedvendor/directory (go mod vendor;go work vendorfor a workspace) whosevendor/modules.txt… still records one that was removed", with the fixgo work vendor. - Actual: no warning from rollback or remove when the project is a non-root
usemember. Exit 0, and the workspace no longer builds.
Matrix (Linux)
| go | use ./a member: rollback/remove warn |
use . root: rollback warns |
|---|---|---|
| 1.22.12 | fail (silent, build broken) | — |
| 1.24.7 | fail (3×, rollback and remove) | pass |
| 1.26.8 | fail | — |
| < 1.22 | n/a (no go work vendor) |
n/a |
macOS and Windows: untested (probe branches are blocked in this routine). Vendored mode (.socket/vendor/golang/) goes through the same detect_owner prefix check, so it is likely affected, but I didn't test it (it needs a mock patch service).
The open PR stack #1764/#1765 does not fix it: I built #1765's head (pr1765). There a single-member patch still goes into a/go.mod, and the same repro gives rollback warnings: [] and then "inconsistent vendoring".
Suspect code
crates/socket-patch-core/src/vendor/go_consumer_sync.rs:580: the stale loop filtersrecordedbysocket_owned(). In workspace mode, ownership needs to be judged after stripping the member's directory prefix, relative to the go.work directory (assame_replacementalready does for the forward check).crates/socket-patch-core/src/vendor/go_mod_edit.rs:88:detect_owneris root-anchored by design (a user's../sibling/.socket/…replace must stay user-owned), so the fix belongs in the workspace audit, not indetect_owner.
Tested on main b787454 (5.0.1+171).
- 主要言語
- Rust
- スター
- 8
- フォーク
- 2
- 平均マージ
- 19時間 31分
- マージ済み PR(30日)
- 686
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
SocketDev/socket-patch のほかの issue
-
bug bughunt pm:npm
難易度 4/5 3〜5日 初心者へのやさしさ 53/100
SocketDev/socket-patch#1827 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Go apply, apply --check and vex treat a module that is only another module's replace target as built, so the patch is reported applied and attested while go builds the unpatched code対応中かも @mikolalysenko が今日担当しました。 オープンagent:claimed agent:triaged bug bughunt pm:go priority:p2
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
SocketDev/socket-patch#1823 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
Vendored gem mode writes the rewired `gem` line of a CRLF Gemfile with an LF ending, leaving the Gemfile with mixed line endings対応中かも @mikolalysenko が今日担当しました。 オープンagent:claimed agent:triaged bug bughunt pm:bundler priority:p1
難易度 3/5 1〜2日 初心者へのやさしさ 25/100
SocketDev/socket-patch#1821 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
CI perf: workflow_dispatch of CI — Windows-only janitor fixes re-run the full Linux + macOS nightly matrix (~100 min/day, ~30 macOS)対応中かも @mikolalysenko が今日担当しました。 オープンagent:claimed agent:triaged ci-perf priority:p3
難易度 4/5 3〜5日 初心者へのやさしさ 1/100
SocketDev/socket-patch#1818 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
Nightly Windows: 3 Go workspace unit tests fail (Unix-only GOWORK paths)対応中かも @mikolalysenko が今日担当しました。 オープンagent:claimed agent:triaged ci-janitor priority:p3
難易度 3/5 1〜2日 初心者へのやさしさ 35/100
SocketDev/socket-patch#1815 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
SocketDev/socket-patch の issue をすべて見る
似ている issue
-
bug dependencies kind:fix priority: P3 ready-for-agent
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
shep-pm/shep#1318 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 2 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
swc-project/swc-next#1165 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
Alive24/shea-symphony#574 ·
-
難易度 1/5 1時間未満 初心者へのやさしさ 84/100
メンテナーはふだん 1 日以内に返信