You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit e0916be
Browse filesBrowse the repository at this point in the historyBrowse files
Fix Go stale go.sum line after a downgrade (#1862) (#1893)
* Start fix for #1840
Assisted-by: Claude Code:claude-opus-5-5
* Refuse Go patches built only via a dep's fork
In a go 1.16 module, when a dependency imports a fork that the root
go.mod replaces with the patched upstream module, apply reported the
patch applied, apply --check said in sync and vex attested
not_affected, while go build linked the unpatched code.
The root go.mod of an unpruned graph does not list modules that only
a dependency requires, but its replace still applies to them. The
replace-target check only trusted a fork listed in the root require,
so it missed this shape. Now, in an unpruned graph, such a replace
counts as in effect unless go.mod requires the patched module itself.
Fixes#1840
Assisted-by: Claude Code:claude-opus-5-5
* Read the go 1.16 module graph for fork replaces
The first fix guessed that a fork replace in a go 1.16 module is in
effect whenever go.mod doesn't list the fork. That refused working
patches when go mod tidy kept a replace nothing uses, and the hosted
rewriter then removed a working Socket replace. It also missed a fork
a dependency raises to the replaced version.
Now, when an unpruned go.mod has a module-to-module replace, the
module graph is read from the module cache, the same walk go.work
projects use, and the fork's selected version decides. apply,
apply --check, the hosted rewriter and VEX discovery all use it. When
the cache lacks go.mod files, the safe answer stays: the patch is not
reported built.
Refs #1840
Assisted-by: Claude Code:claude-opus-5-5
* Declare the go.mod files the graph walk reads
Reading the go 1.16 module graph went around the project view, which
ended read recording for every project: VEX discovery asked for the
raw disk root even with no Go files, so discovery could no longer be
reused between passes. Now the graph is read only when go.mod needs
it, and the root go.mod and any directory replacement's go.mod are
declared as reads, so a change to them still invalidates the cache.
Refs #1840
Assisted-by: Claude Code:claude-opus-5-5
* Keep a hosted Go pin on an unproven fork replace
Without every go.mod of a go 1.16 module graph in the module cache,
a fork replace is only suspected of bypassing the Socket pin. That
guess now refuses a new pin but no longer removes an existing one
that may be working. A partial graph is no longer trusted as proof
that the fork is at a lower version. Socket's own hosted replaces no
longer trigger a graph walk.
Refs #1840
Assisted-by: Claude Code:claude-opus-5-5
* Start fix for #1862
Assisted-by: Claude Code:claude-opus-5-5
* Don't trust a go.sum line a downgrade left
In a go 1.16-or-older module, `go get M@<lower>` lowers go.mod's
require but keeps the old version's go.sum lines until `go mod tidy`.
socket-patch took the highest go.sum zip line as the version the build
selects, so after a downgrade apply wrote an unused replace that
apply --check and vex then reported as patched, or refused a patch for
the version the build really uses (#1862).
When go.mod requires a module below one of its go.sum zip lines, read
the module graph from the module cache and use the version MVS picks.
When the cache can't answer, fail closed: apply refuses with a remedy,
apply --check reports drift, and vex and the hosted rewriter don't
attest or pin the patch.
Assisted-by: Claude Code:claude-opus-5-5
* Test Go downgrades that leave go.sum lines
End-to-end with a real go toolchain, both shapes from #1862: a
downgrade below the patched version (apply refuses, an earlier replace
fails apply --check with and without the module cache, and vex leaves
it out), and a downgrade to the patched version (apply patches it and
the build links the patch).
Assisted-by: Claude Code:claude-opus-5-5
* Let a full Go module graph outrank go.sum
Follow-ups from review of the #1862 fix:
- VEX discovery let a Socket module's own go.sum zip line vouch for a
hosted replace even when a full module graph showed the build picks
another version. That line can be just as stale, so the graph now
wins.
- A patch below go.mod's require reported a leftover go.sum version as
the one the build selects; it now reports go.mod's require, or the
graph's answer when the graph is read.
- The hosted warning says "the module graph selects" when that is
where the answer came from.
- The "unproven" explanation is written once and shared by apply,
apply --check, vex and the hosted rewriter.
Assisted-by: Claude Code:claude-opus-5-5
---------
Co-authored-by: Mikola Lysenko <noreply@anthropic.com>
0 commit comments