GeezerVison

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

Fixes #1840

What was wrong

Take a go 1.16 module (or one with no go directive) where a dependency imports other.com/fork, and the root go.mod has replace other.com/fork => example.com/upstream v1.0.0. A patch for example.com/upstream v1.0.0 was reported as applied. apply --check said it was in sync, and vex attested not_affected. Meanwhile go build linked the unpatched code, because go doesn't chain replaces.

Root cause

replaced_module (crates/socket-patch-core/src/vendor/go_build_list.rs) decides whether a module-to-module replace explains the upstream's go.sum zip line. It only counted the replace when the root go.mod's require listed the fork. In an unpruned graph (go < 1.17), the root go.mod leaves out modules that only a dependency requires. The root's replace still applies to them. Its require versions are also only lower bounds. So go.mod alone can't tell whether the fork is in the build, or at which version.

Fix

• Read the module graph. When go.mod is unpruned and has a user-authored module-to-module replace, ModuleGraph reads it from GOMODCACHE. It reuses GoWorkspace::read_graph_from, the walker go.work projects already use (as a one-member workspace). The fork's MVS-selected version then decides whether the replace is in effect. That covers a fork only a dependency requires, a fork a dependency raises past go.mod's require, a versioned replace shadowing a version-less one, and a stale replace that go mod tidy kept but nothing uses.
• One rule for every caller. select_in / selection_in take the graph. All callers use it: project_selection (agent apply, apply --check, CLI vex), the hosted rewriter (through HostedGoWorkspace.module_graph, read by the hosted engine), and VEX lockfile discovery. The graph is only read when the go.mod needs it. The files it reads in the project (root go.mod, directory replacements' go.mod) are declared to the snapshot view, so cached discovery stays valid.
• Safe fallback. Without a complete graph (the module cache lacks a needed go.mod, or an in-memory view), a replace that may be in effect counts as in effect, so no patch is reported built that isn't. The one exception is when go.mod requires module@version itself: go refuses one module@version under two paths. That guess only refuses a new hosted pin. It never removes an existing one (proves_replace_target). Only a pruned go.mod or a complete graph removes a stale pin.

Tests (red → green)

One existing assertion changed meaning. In inactive_replace_target_keeps_the_zip_as_evidence, the go 1.16 cases "fork not required" and "version-less replace shadowed at go.mod's required version" encoded the bug: go.mod alone can't show the fork is absent, or that a dependency didn't raise it. They now run only for go 1.21. The go 1.16 behavior is covered with and without a graph in unpruned_module_graph_settles_the_fork_replace.

Commands run locally (Linux, go 1.24.7):

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test -p socket-patch-core --all-features: 6999 passed, 4 failed. The 4 failures are chmod-based write-failure tests (copy_tree, vlt_heal, pypi_poetry, pypi_requirements) that can't fail as root (this container runs as uid 0). They're unrelated to Go, and none of their modules is touched by this PR.
• cargo test -p socket-patch-cli --all-features --lib plus every Go-touching suite with SOCKET_PATCH_GO_E2E_REQUIRED=1: e2e_golang_build (33), e2e_golang_hosted_build (25), e2e_golang_workspace_build (31), e2e_vendor_golang_build (44), e2e_golang, e2e_golang_hosted_state, e2e_vex, e2e_vex_redirect, e2e_vex_vendor, ecosystem_dispatch_e2e, in_process_*, cli_apply_silent: all pass.
• The full cargo test --workspace (189 CLI test binaries) doesn't fit this container's disk, so CI covers the rest.

/code-review high findings not fixed

• Module-cache reads aren't in the snapshot read set. If the cache gains a missing go.mod between two passes of one command, a reused discovery keeps its safe verdict ("not built") until the next run. Cached module versions are immutable, and the stale answer is always the conservative one.
• exclude directives aren't applied by the graph walker. That's the same pre-existing limitation as go.work mode. An excluded fork version can only make a patch refused, never falsely attested.
• "Graph rebuilt per patched module" in project_selection: the graph is read only for a module that an unpruned go.mod's fork replace targets (needs_module_graph), not for every patch.
• let in_effect = …; in_effect in replaced_module is required: the iterator borrows entries, a local, so it can't be the tail expression (E0597). Clippy is clean.

Out of scope: GoWorkspace::selection never returns ReplaceTarget, so the #1823/#1840 shapes inside a go.work workspace aren't detected. That's pre-existing and not part of #1840.

https://claude.ai/code/session_011f9aeNyyce3TLFE4vQrpsJ

Generated by Claude Code