dagger/dagger · error
module provenance: implementation-scoped module %q is not at
Error message
module provenance: implementation-scoped module %q is not attached
What it means
During module provenance computation (ResultCallModule), Dagger wraps the user module in an implementation-scoped handle and requires that handle to carry an EngineResultID. If the scoped ID is nil or its engine result ID is 0, the module instance was never attached to the engine's result/call graph, so its provenance (ref, pin, result reference) cannot be reconstructed. This is an internal consistency check guarding against emitting provenance metadata for an unattached module.
Source
Thrown at core/module.go:2338
func (mod *userMod) ResultCallModule(ctx context.Context) (*dagql.ResultCallModule, error) {
self := mod.self()
if self == nil {
return nil, fmt.Errorf("module provenance: missing module result wrapper")
}
if !self.Source.Valid {
return nil, fmt.Errorf("module provenance: module %q has no source", self.Name())
}
scoped, err := ImplementationScopedModule(ctx, mod.res)
if err != nil {
return nil, fmt.Errorf("module provenance: implementation-scoped module %q: %w", self.Name(), err)
}
scopedID, err := scoped.ID()
if err != nil {
return nil, fmt.Errorf("module provenance: module %q handle ID: %w", self.Name(), err)
}
if scopedID == nil || scopedID.EngineResultID() == 0 {
return nil, fmt.Errorf("module provenance: implementation-scoped module %q is not attached", self.Name())
}
src := self.Source.Value.Self()
var ref, pin string
switch src.Kind {
case ModuleSourceKindLocal:
ref = filepath.Join(src.Local.ContextDirectoryPath, src.SourceRootSubpath)
case ModuleSourceKindGit:
ref = src.Git.CloneRef
if src.SourceRootSubpath != "" {
ref += "/" + strings.TrimPrefix(src.SourceRootSubpath, "/")
}
if src.Git.Version != "" {
ref += "@" + src.Git.Version
}
pin = src.Git.Commit
case ModuleSourceKindDir:
default:View on GitHub (pinned to 82ba2681db)
Solutions
- Upgrade the dagger CLI and engine to matching, current versions so module instances are attached with engine result IDs as expected
- Retry the operation — if it came from a stale/cached module handle, re-load the module (fresh dagger connect / ModuleSource resolution)
- If you are developing engine code, ensure ImplementationScopedModule output is ID()'d only after the module result has been registered via the dagql server
- File a bug with the dagger trace/telemetry if it reproduces on current versions; this path should be unreachable in normal flows
Example fix
// before (internal flow, conceptually)
scopedID, _ := scoped.ID()
use(scopedID) // panics/errors later: nil / EngineResultID()==0
// after
if scopedID == nil || scopedID.EngineResultID() == 0 {
return nil, fmt.Errorf("module provenance: implementation-scoped module %q is not attached", self.Name())
}
use(scopedID) Defensive patterns
Strategy: retry
Validate before calling
// before relying on provenance
id, err := scoped.ID()
if err != nil || id == nil || id.EngineResultID() == 0 {
// re-load module via normal load path before emitting provenance
} Try / catch
// Go
res, err := mod.ResultCallModule(ctx)
if err != nil {
if strings.Contains(err.Error(), "is not attached") {
// re-load module / retry once with a fresh session
}
return err
} Prevention
- Keep dagger CLI and engine versions in lockstep
- Always load modules through the standard module-loading path
- Re-load module handles instead of caching them across sessions
When it happens
Trigger: Calling ResultCallModule (e.g. while building a function-call provenance record for Dagger Cloud / engine telemetry) on a userMod whose implementation-scoped module ID is nil or whose EngineResultID() is 0 — i.e. the module was instantiated without being registered as an engine result.
Common situations: Running a module function in an engine/CLI version mismatch where the result-call plumbing didn't attach the module; calling engine internals out of order in custom code; telemetry/provenance emission for a module created programmatically rather than via the normal module-loading path.
Related errors
- module provenance: unexpected module source kind %q
- install user module: missing module result wrapper
- module type lookup: missing module result wrapper
- module object type %q is missing module result wrapper
- failed to get caller implementation-scoped module: %w
AI-assisted analysis of dagger/dagger@82ba2681db (2026-09-05).
Data as JSON: /api/errors/bdc12ec353de7f03.
Report an issue: GitHub.