golang/go · error

%s: %w

Error message

%s: %w

What it means

Thrown in the package-loading loop (load.go:1218) when updateRoots returns an error that is a *mvs.BuildListError and the failing module was one newly added (tracked in modAddedBy). Instead of reporting the raw module-level error, it wraps it with the importing package's stack text (pkg.stackText()) so the user sees the import chain that led to the broken module. The %w verb preserves error unwrapping.

Source

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

		// We ran updateRequirements before resolving missing imports and it didn't
		// make any changes, so we know that the requirement graph is already
		// consistent with ld.pkgs: we don't need to pass ld.pkgs to updateRoots
		// again. (That would waste time looking for changes that we have already
		// applied.)
		var noPkgs []*loadPkg
		// We also know that we're going to call updateRequirements again next
		// iteration so we don't need to also update it here. (That would waste time
		// computing a "direct" map that we'll have to recompute later anyway.)
		direct := pld.requirements.direct
		rs, err := updateRoots(ld, ctx, direct, pld.requirements, noPkgs, toAdd, pld.AssumeRootsImported)
		if err != nil {
			// If an error was found in a newly added module, report the package
			// import stack instead of the module requirement stack. Packages
			// are more descriptive.
			if err, ok := err.(*mvs.BuildListError); ok {
				if pkg := modAddedBy[err.Module()]; pkg != nil {
					pld.error(fmt.Errorf("%s: %w", pkg.stackText(), err.Err))
					break
				}
			}
			pld.error(err)
			break
		}
		if slices.Equal(rs.rootModules, pld.requirements.rootModules) {
			// Something is deeply wrong. resolveMissingImports gave us a non-empty
			// set of modules to add to the graph, but adding those modules had no
			// effect — either they were already in the graph, or updateRoots did not
			// add them as requested.
			panic(fmt.Sprintf("internal error: adding %v to module graph had no effect on root requirements (%v)", toAdd, rs.rootModules))
		}
		pld.requirements = rs
	}
	pld.exitIfErrors(ctx)

	// Tidy the build list, if applicable, before we report errors.

View on GitHub (pinned to b6b368adc5)

Solutions

1. Read the import stack in the error to identify which package import triggered the failing module addition.
2. Fix the root module issue: run 'go get' on the specific failing module, check network/proxy, or verify checksums.
3. If the import is unintended, remove it from your source and re-run 'go mod tidy'.

// When loading packages, detect BuildListError and surface the import stack.
err := loadPackages(ld, ctx)
if err != nil {
    var ble *mvs.BuildListError
    if errors.As(err, &ble) {
        // The error already includes the package import stack;
        // report ble.Module() and ble.Err for diagnostics.
        log.Printf("module %s failed: %v", ble.Module(), ble.Err)
    }
}

When it happens

Trigger: During package loading, a newly-added module requirement fails to build its dependency graph (BuildListError), and that module was added because some package imported it. The modAddedBy map links the module to the importing package, enabling a richer error message.

Common situations: 'go get' or 'go mod tidy' adds a dependency whose transitive graph is broken (missing module, checksum failure, etc.). The error surfaces the import path that triggered the addition, helping locate the offending import.

Related errors

• error loading go %s module graph: %w
• requested Go version %s cannot load module graph (requires G
• internal error: a requirement on %v is needed but was not ad
• %s@%s used for two different module paths (%s and %s)
• %s loaded from %v, but go %s would fail to locate it in %s

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