golang/go · error

%s: %v

Error message

%s: %v

What it means

In the generic action-completion path of Builder.do, when an action's Actor.Act returned an error and AllowErrors is false, the error is re-wrapped with the package ImportPath (unless it already carries that path via an ImportPathError). This produces the familiar 'example.com/pkg: <underlying error>' message in build output.

Source

Thrown at src/cmd/go/internal/work/exec.go:177

		if a.json != nil {
			a.json.TimeDone = time.Now()
		}

		// The actions run in parallel but all the updates to the
		// shared work state are serialized through b.exec.
		b.exec.Lock()
		defer b.exec.Unlock()

		if err != nil {
			if b.AllowErrors && a.Package != nil {
				if a.Package.Error == nil {
					a.Package.Error = &load.PackageError{Err: err}
					a.Package.Incomplete = true
				}
			} else {
				if a.Package != nil {
					if ipe, ok := errors.AsType[load.ImportPathError](err); !ok || ipe.ImportPath() != a.Package.ImportPath {
						err = fmt.Errorf("%s: %v", a.Package.ImportPath, err)
					}
				}
				sh := b.Shell(a)
				sh.Errorf("%s", err)
			}
			if a.Failed == nil {
				a.Failed = a
			}
		}

		for _, a0 := range a.triggers {
			if a.Failed != nil {
				if a0.Mode == "test barrier" {
					// If this action was triggered by a test, there
					// will be a test barrier action in between the test
					// and the true trigger. But there will be other
					// triggers that are other barriers that are waiting
					// for this one. Propagate the failure to the true

View on GitHub (pinned to b6b368adc5)

Solutions

1. Read the wrapped message after the colon — that's the real error to fix.
2. Fix the underlying compile/link/dependency error in the named package.
3. Use 'go build -x' for full command tracing if the inner error is unclear.
4. If AllowErrors is desired (continue past failures), use 'go build ./...' which sets it for multi-package runs.

Example fix

// before
$ go build ./...
// example.com/pkg/internal/foo: undefined: foobar

// after — fix the underlying error in the named package
// edit pkg/internal/foo/foo.go: rename or define 'foobar'
$ go build ./...

// This is a wrapper; surface the inner error to the user/CI log.
if perr, ok := err.(*load.PackageError); ok {
    log.Printf("build failed for %s: %v", perr.ImportStack, perr.Err)
} else {
    log.Printf("build failed: %v", err)
}

When it happens

Trigger: Any failed package-level build action whose error doesn't already identify its package. This is the outer wrapper — the inner error is the real cause (compile error, missing dep, tool failure). It is not itself the root cause; it adds package context.

Common situations: A compile error in a dependency; a missing import; a tool invocation failure during build; any error that bubbles up through the action executor for a Package action.

Related errors

• multiple //go:build comments
• import cycle not allowed
• use of vendored package not allowed
• binary-only packages are no longer supported
• import cycle not allowed in test

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