{"record":{"id":"e45cbf450939b0b3","repo":"golang/go","slug":"s-loaded-from-v-but-go-s-would-select-v","errorCode":null,"errorMessage":"%s loaded from %v,\n\tbut go %s would select %v\n","messagePattern":"(.+?) loaded from (.+?),\n\tbut go (.+?) would select (.+?)\n","errorType":"exception","errorClass":null,"httpStatus":null,"severity":"error","filePath":"src/cmd/go/internal/modload/load.go","lineNumber":2254,"sourceCode":"\t\t\t// unpruned graph due to a newer-than-latest dependency that is normally\n\t\t\t// pruned out.\n\t\t\t//\n\t\t\t// This could also occur if the source code for the module providing the\n\t\t\t// package in the pruned graph has a checksum error, but the unpruned\n\t\t\t// graph upgrades that module to a version with a correct checksum.\n\t\t\t//\n\t\t\t// pkg.err should have already been logged elsewhere — along with a\n\t\t\t// stack trace — so log only the import path and non-error info here.\n\t\t\tsuggestUpgrade = true\n\t\t\tpld.error(fmt.Errorf(\"%s failed to load from any module,\\n\\tbut go %s would load it from %v\", pkg.path, compatVersion, mismatch.mod))\n\n\t\tcase pkg.mod != mismatch.mod:\n\t\t\t// The package is loaded successfully by both Go versions, but from a\n\t\t\t// different module in each. This could lead to subtle (and perhaps even\n\t\t\t// unnoticed!) variations in behavior between builds with different\n\t\t\t// toolchains.\n\t\t\tsuggestUpgrade = true\n\t\t\tpld.error(fmt.Errorf(\"%s loaded from %v,\\n\\tbut go %s would select %v\\n\", pkg.stackText(), pkg.mod, compatVersion, mismatch.mod.Version))\n\n\t\tdefault:\n\t\t\tbase.Fatalf(\"go: internal error: mismatch recorded for package %s, but no differences found\", pkg.path)\n\t\t}\n\t}\n\n\tpld.switchIfErrors(ctx)\n\tsuggestFixes()\n\tpld.exitIfErrors(ctx)\n}\n\n// scanDir is like imports.ScanDir but elides known magic imports from the list,\n// so that we do not go looking for packages that don't really exist.\n//\n// The standard magic import is \"C\", for cgo.\n//\n// The only other known magic imports are appengine and appengine/*.\n// These are so old that they predate \"go get\" and did not use URL-like paths.","sourceCodeStart":2236,"sourceCodeEnd":2272,"githubUrl":"https://github.com/golang/go/blob/b6b368adc57c96c3151d224d172029f233ead2c3/src/cmd/go/internal/modload/load.go#L2236-L2272","documentation":"Emitted by 'go mod tidy' compatibility check when a package loads successfully under both the current and the -compat Go versions, but from different modules (pkg.mod != mismatch.mod). The toolchain flags this because builds could silently vary in behavior depending on which Go version compiles them.","triggerScenarios":"Running 'go mod tidy' where the pruned graph resolves an import to one module while the older unpruned graph selects a different module for the same import path — e.g. a package moved between two modules in the same project, or a fork and upstream both provide the path.","commonSituations":"A multi-module repository split a package into a new module; a 'replace' directive affects one toolchain's resolution but not the other; an 'incompatible' (+incompatible) version vs. a properly versioned v2+ module both provide the path.","solutions":["Run the suggested upgrade path: 'go mod tidy -go=<compatVersion> && go mod tidy' so both graphs agree.","Add an explicit 'require' (and, if needed, a 'replace') that pins the module you want both toolchains to select.","If only the current toolchain matters, re-run 'go mod tidy -compat=<yourGoVersion>'.","Verify no competing 'replace' directives or vendored modules are causing the divergence with 'go list -m all'."],"exampleFix":"// before\n$ go mod tidy\n// error: example.com/pkg loaded from example.com/mod@v1.2.0,\n// \tbut go 1.20 would select v1.5.0\n\n// after: align the selection\n$ go get example.com/mod@v1.5.0 && go mod tidy","handlingStrategy":"validation","validationCode":"// Ensure both toolchains select the same module for each import:\n//   diff <(GOFLAGS=-mod=mod go list -m all) <(go list -m all)\n// Any difference in the module providing a package is a divergence to resolve with an explicit require/replace.","typeGuard":null,"tryCatchPattern":null,"preventionTips":["Pin module versions explicitly with 'require' rather than relying on MVS tie-breaking.","Audit 'replace' directives — they can cause one toolchain to diverge from another.","For v2+ modules, use the versioned path suffix consistently (/v2) to avoid +incompatible ambiguity."],"tags":["go-modules","go-mod-tidy","graph-pruning","compatibility","module-selection"],"backgroundTag":null,"analyzedSha":"b6b368adc57c96c3151d224d172029f233ead2c3","analyzedAt":"2026-08-12T00:22:02.250Z","schemaVersion":2},"datasetVersion":"2026-08-12T13:17:24.610Z"}