golang/go · warning

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

Error message

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

What it means

Thrown by checkTidyCompatibility (load.go:2203) when a package currently loads successfully from a module, but under the older compat Go version's module graph it would not be locatable (an ImportMissingError). The error reports the package's import stack, the module it loads from now, the compat version, and the module version the older Go would select instead. This warns that reproducibility with the older Go version would break. suggestEFlag is set to true so the fix hints recommend -e.

Source

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

		switch {
		case mismatch.err != nil:
			// pkg resolved successfully, but errors out using the requirements in rs.
			//
			// This could occur because the import is provided by a single root (and
			// 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 {

View on GitHub (pinned to b6b368adc5)

Solutions

  1. Run 'go mod tidy -e' to proceed despite the compat mismatch (as the error's fix hints suggest).
  2. Alternatively, update the '-compat' flag to match the oldest Go version you actually need reproducibility with: 'go mod tidy -compat=1.23'.
  3. If reproducibility with the old version is not needed, set '-compat' to the current go directive version.

Example fix

# before — compat mismatch on tidy
go mod tidy
# ... loaded from X, but go 1.22 would fail to locate it

# after — proceed or adjust compat
go mod tidy -e
# or:
go mod tidy -compat=1.23
Defensive patterns

Strategy: fallback

Prevention

When it happens

Trigger: During 'go mod tidy', a package is imported that resolves under the current (pruned) graph but would be unresolved under the compat version's (unpruned) graph. This happens when a transitive dependency upgraded a module to a version that drops the package, or when graph pruning hides ambiguity that the older unpruned graph would expose.

Common situations: Bumping the 'go' directive in go.mod to a newer version that uses graph pruning, while a dependency's version drift means older Go versions cannot find a package. After 'go get' upgrades that move packages between module versions.

Related errors


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