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

[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/upstream@v1.0.0: 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/upstream@v1.0.0/ 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/upstream@v1.0.0 --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/socket-patch-linux-x64-gnu@5.0.1) 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 (Go apply and vendor break every build in projects with a committed vendor/ directory (modules.txt not synced), while apply --check and VEX report success #343, Go apply and vendor wire in a patched module whose go.mod raises or adds a requirement without syncing the consumer go.mod/go.sum, so every default go build fails while apply, --check and VEX report success #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.