dagger/dagger · error

%s %q: %w

Error message

%s %q: %w

What it means

moduleLoadErr is the standard wrapper for primary-module load failures: 'loading module "<ref>": ...' (or 'loading extra module "<ref>": ...' when the request kind is moduleLoadKindExtra). It attaches the requested module ref to whatever error the module install (serveModule) produced, so users see which -m / workspace module failed and why.

Source

Thrown at engine/server/session_workspaces.go:1912

}

// moduleLoadFailure is the API-facing record of a skipped module: its name
// (matching the skipped-module span), its workspace directory (so generate
// can tell whether the run regenerated it) and the described message.
func moduleLoadFailure(mod pendingModule, err error) core.ModuleLoadFailure {
	return core.ModuleLoadFailure{
		Name:    moduleProgressName(mod),
		Dir:     mod.WorkspaceDir,
		Message: core.DescribeLoadFailure(err),
	}
}

func moduleLoadErr(load moduleLoadRequest, err error) error {
	prefix := "loading module"
	if load.mod.Kind == moduleLoadKindExtra {
		prefix = "loading extra module"
	}
	return fmt.Errorf("%s %q: %w", prefix, load.mod.Ref, err)
}

func entrypointTierPriority(kind moduleLoadKind) int {
	switch kind {
	case moduleLoadKindExtra:
		return 3
	case moduleLoadKindAmbient:
		return 1
	default:
		return 0
	}
}

func shouldPreferEntrypointNomination(
	currentLoad moduleLoadRequest,
	currentResolved resolvedModuleLoad,
	nextLoad moduleLoadRequest,
	nextResolved resolvedModuleLoad,

View on GitHub (pinned to 82ba2681db)

Solutions

1. Read the inner error after the ref to see the actual serveModule failure.
2. Fix the module source at the given ref: valid dagger.json, compilable code, correct SDK.
3. Regenerate the module (dagger develop) if generated code is stale.
4. For extra modules, verify the -m path/ref is correct and accessible.

Example fix

// before
$ dagger -m ./modules/typo call fn
error: loading module "./modules/typo": ...
// after
$ dagger -m ./modules/my-module call fn  # correct path, valid dagger.json

// preflight for -m usage
if _, err := os.Stat(filepath.Join(modulePath, "dagger.json")); err != nil { return fmt.Errorf("%s is not a module", modulePath) }

// surface both ref and cause: message is already "loading [extra] module \"<ref>\": <cause>"
if err != nil { if strings.HasPrefix(err.Error(), "loading ") { log.Fatalf("%v", err) } }

When it happens

Trigger: Any primary or extra module load (from dagger -m, workspace modules, ambient entrypoints) where serveModule for the primary module fails after related modules were served successfully.

Common situations: -m pointing at a module with compile errors or invalid dagger.json; entrypoint constructor failing (though SkipConstructor is used for deps); ref resolving to a module that can't be installed into the session; stale generated code after an SDK upgrade.

Related errors

• function %q returns type %q with no further functions availa
• module ref cannot be empty
• module source ref cannot be empty
• %d workspace module(s) could not be loaded (--require-load)
• list installed modules: %w

AI-assisted analysis of dagger/dagger@82ba2681db (2026-09-05). Data as JSON: /api/errors/f783f0baa30cf6da. Report an issue: GitHub.