[Mikola Lysenko (mikolalysenko)]

LLM Description written by Claude Code:claude-opus-5-5

Fixes #1777

What users saw

Take a Go project with a committed vendor/ and a vendored socket patch,
with go mod vendor re-run as the forward warning asks. Undoing the patch
with vendor --revert, rollback or remove <purl> drops the go.mod
replace and exits 0 with no warning. But vendor/modules.txt still
records the removed replace, so every default build fails with
"inconsistent vendoring". vendor --check also passed afterwards.
Agent-mode rollback already warned about this (#343).

Root cause

All three undo commands go through the shared vendored revert step
(VendoredBackend::revert), but none of them runs the
go_consumer_sync audit afterwards:

• vendor --revert (run_revert) never called it.
• rollback called it only after an agent-mode (is_local_go) Go result.
• remove had no Go consumer audit at all.

vendor --check audits Go state only per ledger entry, so once the revert
removed the entry, it no longer saw the stale record.

Fix

• VendoredBackend::go_undo_warnings audits the Go consumer state once
  after a revert and returns the issues of the Go modules that revert
  unwired (dry runs and kept entries excluded), keyed by ledger entry.
  vendor --revert, rollback's vendored leg and remove call it, so each
  one warns go_vendor_modules_txt_out_of_sync and names go mod vendor,
  or go work vendor in a workspace. It is not built into revert
  itself: the forward vendor run also reverts dropped entries, and it
  already audits once at the end of the run.
• vendor --check runs the audit once and fails on a modules.txt that
  still records a socket replace go.mod no longer has, for a module with
  no Go ledger entry left (go_vendor_modules_txt_out_of_sync, naming
  the regeneration command).
• docs/ecosystems.md: the "Files go derives from go.mod" section now
  names vendor --revert and remove among the commands that warn.

No wrapper changes: the npm/PyPI/gem wrappers only dispatch the binary.

Tests

New e2e tests in e2e_vendor_golang_build.rs (real go 1.24.7, hermetic
file GOPROXY). Each one runs vendor, then go mod vendor (or
go work vendor), then the undo, and checks that:

1. the default build really fails with "inconsistent vendoring" (fixture proof);
2. the undo envelope carries go_vendor_modules_txt_out_of_sync;
3. apply --check and vendor --check exit 1 and name the regeneration command;
4. after the regeneration, the project builds PRISTINE and vendor --check
   no longer reports the modules.txt drift.

#1777 variant	Test	Without fix	With fix
vendor --revert	vendor_revert_needs_go_mod_vendor_with_committed_vendor_dir	FAILED ("must name the vendor/modules.txt regeneration")	ok
rollback	vendored_rollback_needs_go_mod_vendor_with_committed_vendor_dir	FAILED (same)	ok
remove <purl>	vendored_remove_needs_go_mod_vendor_with_committed_vendor_dir	FAILED (same)	ok
go.work (use .) + vendor --revert	vendor_revert_needs_go_work_vendor_in_workspace	FAILED (same)	ok
go.work (use .) + rollback	vendored_rollback_needs_go_work_vendor_in_workspace	FAILED (same)	ok
go.work (use .) + remove	vendored_remove_needs_go_work_vendor_in_workspace	FAILED (same)	ok

Local results:

• cargo test -p socket-patch-cli --all-features --test e2e_vendor_golang_build --test e2e_golang_build --test e2e_golang_workspace_build --test e2e_golang_hosted_build: 44 + 27 + 16 + 22 passed
• Same six tests with crates/socket-patch-cli/src reset to origin/main: 6 FAILED; with the fix: 6 ok
• cargo fmt --all -- --check: ok. cargo clippy --workspace --all-features -- -D warnings: ok
• cargo test --workspace --all-features: Go suites and everything this diff touches pass. A dozen tests in untouched areas (pypi/vlt/repair write-failure and copy_tree permission tests, e2e_bun_lockb) fail locally because the sandbox runs as root, which ignores the chmod-based failure injection, or because of the known Nightly e2e_bun_lockb red: offline takeover test predates #1648 #1770 bun issue. CI runs them non-root.

CI

All 81 check runs on 61717de are green or skipped. The "Go patch
compatibility" workflow, which would run these Go e2e suites on a PR, is
disabled by hand in the repo (last run 2026-10-09), so the Go e2e evidence
above comes from local runs. Bugbot is paused for the team (unpaid Cursor
invoice). @bugbot review was posted at 61717de and needs re-triggering
once billing is fixed.

Scope notes

• Non-root workspace member (use ./a): the issue notes this overlaps
  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" #1766. Recognizing a member's ./a/.socket/... replace in modules.txt
  is what Fix stale go.work vendor warning for members (#1766) #1767 fixes in go_consumer_sync. This PR makes the vendored
  undo paths run that same audit, so once Fix stale go.work vendor warning for members (#1766) #1767 lands they pick up its
  member handling too. Not tested here, to avoid conflicting with Fix stale go.work vendor warning for members (#1766) #1767.
• apply --check with no manifest file at all (a get --mode vendored
  project) still exits 0 under its "nothing to verify" contract. For that
  shape, vendor --check now reports the drift.
• /code-review high findings and how they were handled:
  • Fixed: the forward reconcile no longer audits mid-run (no double warning).
  • Fixed: only issues for unwired modules are reported, so nothing
    unrelated shows up under the wrong purl. This also removed the rollback
    dedup.
  • Fixed: the vendor --check audit runs once.
  • Fixed: the test also checks stdout.
  • Not changed: vendor --check flags a stale agent-mode socket record
    too. It breaks the same default build, and apply --check already
    reports it.
  • Not changed: rollback's agent-leg audit runs before the vendored leg.
    That ordering predates this PR.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Bugbot is paused — your team has an unpaid invoice

Bugbot is paused because your team has an unpaid invoice.

Pay it from the billing page in the Cursor dashboard and Bugbot resumes automatically.

(requestId: 07f7d8cd-ad93-4bf5-8cad-340e64c8d681)

[cursor]

Bugbot is paused — your team has an unpaid invoice

Bugbot is paused because your team has an unpaid invoice.

Pay it from the billing page in the Cursor dashboard and Bugbot resumes automatically.

(requestId: 289a9925-247f-41aa-802e-1db86d92cdf2)

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

Bugbot is paused — your team has an unpaid invoice

Bugbot is paused because your team has an unpaid invoice.

Pay it from the billing page in the Cursor dashboard and Bugbot resumes automatically.

(requestId: 1fd7f5ba-84e0-4cd6-a600-2c823e408cf6)