%s failed to load from any module, but go %s would load it

Error message

%s failed to load from any module,
	but go %s would load it from %v

What it means

Emitted by 'go mod tidy' compatibility check. The package failed to load under the current (pruned) module graph — its underlying pkg.err was already reported separately — but when the import is re-resolved under the older Go version's unpruned requirements, it loads successfully from mismatch.mod. This means an older Go would build code that the current toolchain cannot resolve.

Source

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

		case pkg.err != nil:
			// pkg had an error in with a pruned module graph (presumably suppressed
			// with the -e flag), but the error went away using an unpruned graph.
			//
			// This is possible, if, say, the import is unresolved in the pruned graph
			// (because the "latest" version of each candidate module either is
			// unavailable or does not contain the package), but is resolved in the
			// unpruned graph due to a newer-than-latest dependency that is normally
			// pruned out.
			//
			// This could also occur if the source code for the module providing the
			// package in the pruned graph has a checksum error, but the unpruned
			// graph upgrades that module to a version with a correct checksum.
			//
			// pkg.err should have already been logged elsewhere — along with a
			// stack trace — so log only the import path and non-error info here.
			suggestUpgrade = true
			pld.error(fmt.Errorf("%s failed to load from any module,\n\tbut go %s would load it from %v", pkg.path, compatVersion, mismatch.mod))

		case pkg.mod != mismatch.mod:
			// The package is loaded successfully by both Go versions, but from a
			// different module in each. This could lead to subtle (and perhaps even
			// unnoticed!) variations in behavior between builds with different
			// toolchains.
			suggestUpgrade = true
			pld.error(fmt.Errorf("%s loaded from %v,\n\tbut go %s would select %v\n", pkg.stackText(), pkg.mod, compatVersion, mismatch.mod.Version))

		default:
			base.Fatalf("go: internal error: mismatch recorded for package %s, but no differences found", pkg.path)
		}
	}

	pld.switchIfErrors(ctx)
	suggestFixes()
	pld.exitIfErrors(ctx)
}

View on GitHub (pinned to b6b368adc5)

Solutions

Upgrade to the older toolchain's selected versions per the printed hint: 'go mod tidy -go=<compatVersion> && go mod tidy'.
Run 'go mod tidy -e' to tolerate the unresolved package and inspect which module 'go %s would load it from' (mismatch.mod) via 'go list -m -json <mismatch.mod>'.
Add an explicit require for the module/version named by mismatch.mod so it is no longer pruned out.
If older-Go reproducibility is unnecessary, rebuild with 'go mod tidy -compat=<yourGoVersion>'.

Example fix

// before
$ go mod tidy
// error: example.com/pkg failed to load from any module,
// 	but go 1.20 would load it from example.com/mod@v1.4.0

// after: pin the version the older graph selected
$ go get example.com/mod@v1.4.0 && go mod tidy

Defensive patterns

Strategy: validation

Validate before calling

// Detect that every import resolves in the compat graph before tidy:
//   go mod tidy -go=<compat> -e 2>&1 | grep 'failed to load from any module'
// If non-empty, add an explicit require for the module printed in the hint.

Prevention

Prefer explicit 'go get <mod>@<ver>' over relying on transitive resolution.
Avoid mixing pruned (go >= 1.17) and unpruned dependencies without testing both graphs.
Run 'go mod verify' periodically to catch checksum issues that diverge between graphs.

When it happens

Trigger: Running 'go mod tidy' where the package is unresolved in the pruned graph (latest candidate module unavailable or missing the package, or a checksum error in source) but a newer-than-latest transitive dependency normally pruned out provides it in the unpruned graph.

Common situations: A dependency bumped its go.mod to 1.17+ so its transitive requirements are pruned for your module, hiding the version that actually provides the import; a module proxy serving a stale 'latest'; source checksum mismatch on the pruned version that the unpruned graph upgrades past.

Related errors

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