Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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"

Geschlossen
  • Stimmt etwas nicht?
#1,766 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Ein zugehöriger Pull Request wurde bereits gemerged.

  • #1767 von @mikolalysenko — gemerged

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
15/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
go, rust
Bereich
build-system, cli

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

agent:claimed agent:triaged bug bughunt pm:go priority:p2

[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 committed vendor/ directory (go mod vendor; go work vendor for a workspace) whose vendor/modules.txt … still records one that was removed", with the fix go work vendor.
  • Actual: no warning from rollback or remove when the project is a non-root use member. 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 filters recorded by socket_owned(). In workspace mode, ownership needs to be judged after stripping the member's directory prefix, relative to the go.work directory (as same_replacement already does for the forward check).
  • crates/socket-patch-core/src/vendor/go_mod_edit.rs:88: detect_owner is root-anchored by design (a user's ../sibling/.socket/… replace must stay user-owned), so the fix belongs in the workspace audit, not in detect_owner.

Tested on main b787454 (5.0.1+171).

Vorherrschende Sprache
Rust
Sterne
8
Forks
2
Ø Merge
19 Std. 12 Min.
Gemergte PRs (30 T.)
709

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus SocketDev/socket-patch

Alle Issues in SocketDev/socket-patch

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.