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

  1. Upgrade the dagger CLI and engine to matching, current versions so module instances are attached with engine result IDs as expected
  2. Retry the operation — if it came from a stale/cached module handle, re-load the module (fresh dagger connect / ModuleSource resolution)
  3. If you are developing engine code, ensure ImplementationScopedModule output is ID()'d only after the module result has been registered via the dagql server
  4. 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

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


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