unknown import path %q: internal error: module loader did no

Error message

unknown import path %q: internal error: module loader did not resolve import

What it means

In module-aware mode (cfg.ModulesEnabled is true), the module loader is expected to resolve every import except 'unsafe'. This error means the resolver returned a result object without setting r.err, but also without producing a resolved package — a condition loadPackageData treats as an internal toolchain bug. The 'internal error' label in the message signals this should not happen under normal use.

Source

Thrown at src/cmd/go/internal/load/pkg.go:979

					// loader said there weren't. Which one is right?
					// Without this special-case hack, the TestScript/test_vet case fails
					// on the vetfail/p1 package (added in CL 83955).
					// Apparently, imports.ShouldBuild biases toward rejecting files
					// with invalid build constraints, whereas ImportDir biases toward
					// accepting them.
					//
					// TODO(#41410: Figure out how this actually ought to work and fix
					// this mess).
				} else {
					data.err = r.err
				}
			}
		} else if r.err != nil {
			data.p = new(build.Package)
			data.err = r.err
		} else if cfg.ModulesEnabled && path != "unsafe" {
			data.p = new(build.Package)
			data.err = fmt.Errorf("unknown import path %q: internal error: module loader did not resolve import", r.path)
		} else {
			buildMode := build.ImportComment
			if mode&ResolveImport == 0 || r.path != path {
				// Not vendoring, or we already found the vendored path.
				buildMode |= build.IgnoreVendor
			}
			data.p, data.err = cfg.BuildContext.Import(r.path, parentDir, buildMode)
		}
		data.p.ImportPath = r.path

		// Set data.p.BinDir in cases where go/build.Context.Import
		// may give us a path we don't want.
		if !data.p.Goroot {
			if cfg.GOBIN != "" {
				data.p.BinDir = cfg.GOBIN
			} else if cfg.ModulesEnabled {
				data.p.BinDir = modload.BinDir(ld)
			}

View on GitHub (pinned to b6b368adc5)

Solutions

Run go mod tidy to re-resolve dependencies and fix go.sum inconsistencies.
Clear the module cache: go clean -modcache, then re-download with go mod download.
Update to the latest Go patch release — this may be a known toolchain bug that has been fixed.
If reproducible, file a bug at https://github.com/golang/go/issues with go.mod, the import graph, and Go version.

Defensive patterns

Strategy: retry

Validate before calling

// Pre-validate module resolution before building.
func checkModuleResolution() error {
    cmd := exec.Command("go", "mod", "verify")
    if out, err := cmd.CombinedOutput(); err != nil {
        return fmt.Errorf("module verification failed: %w\n%s", err, out)
    }
    return nil
}

Try / catch

// On module resolution internal errors, clean cache and retry.
func buildWithRetry() error {
    err := runBuild()
    if err != nil && strings.Contains(err.Error(), "module loader did not resolve") {
        // Clean cache and re-resolve
        exec.Command("go", "clean", "-modcache").Run()
        if tidyErr := exec.Command("go", "mod", "tidy").Run(); tidyErr != nil {
            return fmt.Errorf("go mod tidy failed: %w", tidyErr)
        }
        err = runBuild() // single retry
    }
    return err
}

Prevention

Run go mod tidy regularly to keep go.sum consistent.
Commit go.sum to version control.
Update the Go toolchain to the latest patch release.
Run go mod verify in CI to detect cache corruption early.
Pin module versions explicitly in go.mod.

When it happens

Trigger: An import that the module resolver silently failed on, returning neither a resolved path nor an error. This indicates corruption in the module cache, a go.sum inconsistency that was silently swallowed, or a genuine bug in the Go toolchain's module resolution path. Only triggers when path != "unsafe" and ModulesEnabled is true.

Common situations: Corrupted module cache ($GOPATH/pkg/mod) after a failed download or disk issue. Network issues during module download that left partial state. Inconsistent go.mod/go.sum after a failed go mod operation. Using a patched or development Go toolchain with resolution bugs.

Related errors

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