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

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: