Vendored Go undo (vendor --revert, rollback, remove) stays silent about a stale vendor/modules.txt, so every build fails with "inconsistent vendoring"

Start in crates/socket-patch-cli/src/commands/vendor.rs at run_revert, compare its forward warning path with go_consumer_sync::audit_warnings, then trace the vendored branches in rollback.rs and remove.rs. Read the apply --check / vendor --check handling to see why a stale vendor/modules.txt is not detected once no replacement entry remains. Done means all three undo paths emit go_vendor_modules_txt_out_of_sync and a later check fails until go mod vendor/go work vendor is run; check open PR #1778 before duplicating work.

[agent] Found by the scheduled Go modules bug-hunt routine (ledger #317).

Summary

Take a Go project with a committed vendor/ directory that was patched in vendored mode, 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 status success. None of them warns go_vendor_modules_txt_out_of_sync, and vendor --check and apply --check both exit 0 afterwards. But vendor/modules.txt still records the removed replace, so the next default build fails:

go: inconsistent vendoring in …/c:
	example.com/[email protected]: is marked as replaced in vendor/modules.txt, but not replaced in go.mod

Agent mode handles the same situation correctly. After apply → go mod vendor → rollback, the CLI warns go_vendor_modules_txt_out_of_sync and apply --check exits 1 with "still records a socket-patch replacement … run go mod vendor". This is the #343 fix. Only the vendored undo paths miss it.

Impact

Repos that commit vendor/ are the main audience for vendored mode (air-gapped and frozen CI). There, every vendored undo leaves the default build broken, and nothing tells the user to run go mod vendor. This includes the cleanup a user does when moving away from vendored mode. It's a rewrite that makes the next frozen build fail, while the CLI reports success and its own audits pass.

Expected vs actual

docs/ecosystems.md, "Files go derives from go.mod": apply, vendor, rollback and scan --mode hosted warn with the command that does the regeneration, and apply --check / vendor --check report the disagreement as drift until it is run. The warning covers a vendor/modules.txt that "does not record a socket replace, or still records one that was removed".

• Expected: vendor --revert, rollback and remove warn go_vendor_modules_txt_out_of_sync with go mod vendor (or go work vendor), as agent rollback does, and a later check fails until the regeneration is done.
• Actual: no warning (rollback only reports reinstall_required), exit 0, and both checks exit 0.

Repro

This uses a hermetic HTTP GOPROXY and a local mock of the patch API. POST /v0/orgs/<org>/patches/package returns a granted tarball: an example.com/[email protected]/ module zip with a patched lib.go, plus sha512 integrity, in the vendor/golang.rs mount_go_granted shape. GET …/patches/view/<uuid> returns the record.

export GOFLAGS= GOENV=off GOTOOLCHAIN=local GOPROXY=http://127.0.0.1:$PORT/proxy GOSUMDB=sum.invalid.example
API="--api-url http://127.0.0.1:$PORT --org test-org --api-token fake"
# consumer: go 1.21, require example.com/upstream v1.0.0, go.sum has the upstream lines
go mod vendor && git add -A && git commit -qm vendored-dir
socket-patch get $UUID --mode vendored --yes $API   # exit 0, warns go_vendor_modules_txt_out_of_sync (correct)
go mod vendor && go run .                           # OUT: PATCHED
git add -A && git commit -qm patched

socket-patch vendor --revert --json      # exit 0, status success, warnings: []
socket-patch vendor --check              # exit 0
socket-patch apply --check --offline     # exit 0
go run .                                 # exit 1: inconsistent vendoring (above)
# Same result from `git checkout . && git clean -fd` and then
#   socket-patch rollback --offline --json            -> exit 0, warnings: [reinstall_required]
#   socket-patch remove pkg:golang/example.com/[email protected] --offline --json  -> exit 0, warnings: []

# Control, agent mode on the same project shape:
#   apply --offline; go mod vendor; rollback --offline --json -> warnings: [go_vendor_modules_txt_out_of_sync]
#   apply --check -> exit 1 "still records a socket-patch replacement ..."

The same happens in a go.work workspace after go work vendor, both with use . at the root and in a non-root member (use ./a). The non-root member case overlaps #1766, which is agent mode. Its fix, #1767, only changes the audit in go_consumer_sync.rs, and vendored undo never calls that audit.

OS × version

It isn't a regression: the v5.0.1 release (npm @socketsecurity/[email protected]) behaves the same. Tested on main b787454.

Suspect code

• crates/socket-patch-cli/src/commands/vendor.rs:4417 (run_revert) never calls go_consumer_sync::audit_warnings. The forward path does, at vendor.rs:4013-4026 (#343, #618).
• crates/socket-patch-cli/src/commands/rollback.rs:3319-3329 only audits when a result is_local_go (the agent go-patches leg), so the vendored leg is skipped.
• crates/socket-patch-cli/src/commands/remove.rs has no Go consumer audit at all.
• apply --check / vendor --check never look at a stale modules.txt when no vendored or manifest entry is left, so they pass after the revert.

No probe runs: the sandbox is Linux-only, and the go/modules.txt logic involved is OS-independent.