golang/go · error

%s loaded from %v, but go %s would fail to locate it: %v

Error message

%s loaded from %v,
	but go %s would fail to locate it:
	%v

What it means

Emitted by 'go mod tidy' during the backward-compatibility check (checkTidyCompatibility). It means a package resolves successfully under the current toolchain, but the Go version named by -compat (default: the previous major release) would fail to locate that package when re-resolving the import graph. The trailing mismatch.err prints the concrete reason (e.g. an ambiguous-import or checksum failure seen by the older graph).

Source

Thrown at src/cmd/go/internal/modload/load.go:2208

			// is thus unambiguous in a main module with a pruned module graph) and
			// also one or more transitive dependencies (and is ambiguous with an
			// unpruned graph).
			//
			// It could also occur because some transitive dependency upgrades the
			// module that previously provided the package to a version that no
			// longer does, or to a version for which the module source code (but
			// not the go.mod file in isolation) has a checksum error.
			if _, ok := errors.AsType[*ImportMissingError](mismatch.err); ok {
				selected := module.Version{
					Path:    pkg.mod.Path,
					Version: mg.Selected(pkg.mod.Path),
				}
				pld.error(fmt.Errorf("%s loaded from %v,\n\tbut go %s would fail to locate it in %s", pkg.stackText(), pkg.mod, compatVersion, selected))
			} else {
				if _, ok := errors.AsType[*AmbiguousImportError](mismatch.err); ok {
					// TODO: Is this check needed?
				}
				pld.error(fmt.Errorf("%s loaded from %v,\n\tbut go %s would fail to locate it:\n\t%v", pkg.stackText(), pkg.mod, compatVersion, mismatch.err))
			}

			suggestEFlag = true

			// Even if we press ahead with the '-e' flag, the older version will
			// error out in readonly mode if it thinks the go.mod file contains
			// any *explicit* dependency that is not at its selected version,
			// even if that dependency is not relevant to any package being loaded.
			//
			// We check for that condition here. If all of the roots are consistent
			// the '-e' flag suffices, but otherwise we need to suggest an upgrade.
			if !suggestUpgrade {
				for _, m := range pld.requirements.rootModules {
					if v := mg.Selected(m.Path); v != m.Version {
						suggestUpgrade = true
						break
					}
				}

View on GitHub (pinned to b6b368adc5)

Solutions

1. Follow the printed suggestion: run 'go mod tidy -go=<compatVersion>' then 'go mod tidy' with your version to upgrade the requirements consistently.
2. Run 'go mod tidy -e' to keep the build working while leaving the affected packages unresolved for the older toolchain.
3. If backward compatibility with the older Go is not required, run 'go mod tidy -compat=<yourGoVersion>' (or drop -compat) so the check is skipped.
4. Inspect go.sum / run 'go mod verify' to rule out a checksum corruption on the module providing the package.

Example fix

// before
$ go mod tidy
// error: <pkg> loaded from <mod>,
// 	but go 1.20 would fail to locate it: ...

// after (upgrade the older graph's requirements)
$ go mod tidy -go=1.20 && go mod tidy -go=1.21
// or, if 1.20 compat is not needed
$ go mod tidy -compat=1.21

// Before committing, ensure tidy is reproducible at the compat version:
//   go mod tidy -go=<compat> && go mod tidy
// In CI, run: go mod tidy -compat=$(go mod edit -json | jq -r .Go.Version | cut -d. -f1,2)
// and fail the build if it exits non-zero, so the mismatch is caught pre-merge.

When it happens

Trigger: Running 'go mod tidy' on a module with go >= 1.17 where graph pruning hides a transitive dependency that an older unpruned graph would surface, or where a dependency was upgraded past the version that still contained the imported package, or a checksum error exists in source fetched only by the older graph.

Common situations: Upgrading a module from Go 1.16 to 1.17+ and running 'go mod tidy'; a transitive dependency's latest version dropped the imported package; a replaced or retracted module resolves differently across toolchain versions; CI pinning -compat to an older Go.

Related errors

• %s failed to load from any module, but go %s would load it
• %s loaded from %v, but go %s would select %v
• maximum supported Go version is %s
• can't request explicit version of "tool" pattern
• internal error: a requirement on %v is needed but was not ad

AI-assisted analysis of golang/go@b6b368adc5 (2026-08-12). Data as JSON: /api/errors/78bc27440fd57ae2. Report an issue: GitHub.