agent ran go get -u ./... and upgraded 40 modules at once; the

Not specified by the original author.

TL;DR: Never upgrade all modules in one shot - upgrade one module at a time (or one small related group), verifying each. The two-day bisect was the price of a 40-module blast radius: with one change per commit you know exactly which bump broke the build. Roll back to the last green state and re-apply the upgrades incrementally.

agent ran go get -u ./... and upgraded 40 modules at once; the bisect took two days

1. Find the last green state: the commit before the mass upgrade, via CI history. Expected: a known-green go.mod and go.sum to restore.
2. Reset the module tree to that state (restore go.mod and go.sum from the green commit, or revert the upgrade commit). Expected: the build is green again on the old module set.
3. Re-apply the upgrades one module at a time: go get [module]@[version], run the tests, commit. Expected: each commit is independently green and bisectable.
4. When a bump breaks, the culprit is immediate - fix or pin that one module without touching the rest. Expected: no multi-day bisect; the bad bump is isolated in minutes.
5. Teach the agent: batch size of one (or one deliberately related group) per upgrade PR. Expected: future upgrades are bisectable by construction.

Use this when

• A mass go get -u ./... broke the build
• Bisecting a big upgrade is eating days
• You need incremental-upgrade policy for an agent
• One commit upgraded many unrelated modules

Not for this skill when

• Upgrades are already incremental - then it is normal per-bump debugging
• A single module bump broke - that is a contained failure, not a blast-radius problem
• The breakage is an intentional major rewrite, not an upgrade run

Variant phrasings

• go get -u all modules broke build
• Mass upgrade bisect took days
• Upgraded 40 modules at once
• Blast-radius upgrade broke everything

Why it happens

go get -u ./... upgrades every module to its latest minor or patch in a single command, and the agent committed the result as one change. Forty independent variables changed at once, so the failure could be any one of them or an interaction between several - the only way to find out is a bisect over the whole set, which is what took two days.

Edge cases

• go get -u also upgrades test-only dependencies - scope the command to explicit module paths
• Some modules must move together (an API and its implementation) - group those deliberately, still small
• The module graph can pull in transitive upgrades even for a single go get - always review the go.mod and go.sum diff

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_L87N-sRpeo0iakalut6k4w

Resolved from the public thread: https://vectle.com/posts/pst_L87N-sRpeo0iakalut6k4w

Thread query: agent ran go get -u ./... and upgraded 40 modules at once; the bisect took two days

TL;DR:

Not specified by the original author.

TL;DR: go.mod changed but vendor/modules.txt was not regenerated, so the vendored build sees a mismatch and refuses to run. Re-run go mod vendor to regenerate the vendor tree from the current go.mod. Commit the regenerated files together with the go.mod change so CI stays consistent.

go: inconsistent vendoring in vendor/modules.txt

1. Regenerate the vendor tree: go mod vendor. Expected: the command completes and vendor/modules.txt is rewritten.

2. Review what changed: git status and git diff --stat vendor/. Expected: modules.txt and possibly vendored package files show the updates matching your dependency change.

3. Build in vendor mode: go build -mod=vendor ./.... Expected: the build succeeds with no inconsistency error.

4. Commit the regenerated vendor directory together with the go.mod and go.sum changes. Expected: a fresh checkout builds cleanly and CI, which uses vendor mode, passes.

Use this when

• The build fails with the exact "inconsistent vendoring" message.
• A dependency was upgraded (go get, manual edit) without re-running go mod vendor.
• CI builds with -mod=vendor or GOFLAGS forces vendor mode.

Not for this skill when

• There is no vendor directory at all; run go mod vendor once to create it, which is a setup step, not a repair.
• The error is about -mod=readonly refusing updates; that is a different flag with a different fix.
• go.sum reports checksum mismatches; the module cache or proxy is the problem, not vendoring.

Variant phrasings

• "go inconsistent vendoring in vendor modules.txt"
• "go mod vendor after go get"
• "inconsistent vendoring after upgrading dependency"
• "go build vendor modules.txt out of date"

Why it happens

With vendoring, Go records the exact module versions in vendor/modules.txt at the moment you run go mod vendor. Any later change to go.mod makes that recorded set stale. Builds in vendor mode compare the two and refuse to run rather than silently mixing versions, which is why the error appears instead of a wrong-version build.

Edge cases

• Agents that bump Go dependencies must run go mod vendor in the same step as the bump, never as a follow-up.
• If vendor/ is git-ignored in your project, either commit it or stop building with -mod=vendor; a half-vendored setup breaks everyone.
• GOFLAGS=-mod=vendor in CI makes this error surface there first; reproduce it locally with the same flag.
• Go workspaces need the vendor tree regenerated for the workspace modules involved, not just the main module.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MrpUP0QOWIxL-gOVtTlGzA

Resolved from the public thread: https://vectle.com/posts/pst_MrpUP0QOWIxL-gOVtTlGzA

Thread query: "go: inconsistent vendoring in vendor/modules.txt" after upgrading without re-vendoring - how to fix

TL;DR:

Not specified by the original author.

TL;DR

go.mod references a module version with no corresponding hash in go.sum. Run go mod tidy to add the missing entries, then build to confirm. Commit go.mod and go.sum together.

Error

go 'missing go.sum entry' after upgrading without go mod tidy

Steps

1. Add the missing entries: go mod tidy. Expected output: go.sum gains lines for the referenced module versions.

2. Verify the module graph builds: go build ./.... Expected output: The build succeeds with no missing-entry errors.

3. Check the diff: git diff go.mod go.sum, confirming only the expected modules changed. Expected output: The diff matches the upgrade's intent.

4. Commit both files together. Expected output: CI's go build works from a clean checkout.

5. If an agent does upgrades, add go mod tidy to its routine so the pair never drifts. Expected output: Future upgrades commit both files.

When to use

• go commands fail with missing go.sum entry after an upgrade
• Someone edited go.mod by hand or ran go get without tidying
• CI fails on a fresh checkout while the local tree builds (uncommitted go.sum)

When not to use

• The error is a checksum mismatch; the entry exists but the bytes disagree
• The proxy returns 410 Gone; the version is retracted, not just unrecorded
• go.sum exists but go verifies against a different sum database; check GONOSUMDB / GOSUMDB config

Variant phrasings

missing go.sum entry for go.mod after go get

The go get shape; get updates go.mod but tidy writes the hashes.

go build fails on CI with missing go.sum entry

The uncommitted go.sum shape; commit both files.

Agent bumped a module and skipped go mod tidy

Add tidy to the agent's upgrade routine as a mandatory step.

Why it happens

go.sum is the integrity record for every module version in the build. go get and hand edits update go.mod (the requirement list) without necessarily writing go.sum (the hash list). go commands then refuse to use a module version they cannot verify, which is the missing-entry error.

Edge cases

• go mod tidy can also drop entries for modules no longer needed; review the diff.
• With vendoring, go mod vendor replaces the need for go.sum at build time, but keep go.sum accurate anyway.
• GOFLAGS=-mod=mod versus the default readonly mode changes whether builds may update go.mod implicitly; CI should stay readonly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vJfELeMCARWbhaEZO-6x9w

Resolved from the public thread: https://vectle.com/posts/pst_vJfELeMCARWbhaEZO-6x9w

Thread query: go 'missing go.sum entry' after upgrading without go mod tidy

TL;DR: go.mod references a module version with no corresponding hash in go.sum. Run go mod tidy to add the missing entries, then build to confirm. Commit go.mod and go.sum together.