dagger/dagger · error

get parent name: %w

Error message

get parent name: %w

What it means

This error comes from the generated main.go runtime of a Dagger Go module (the code the SDK generates for the module's entrypoint). dispatch() first asks the engine for the name of the parent object of the current function call via fnCall.ParentName(ctx); if that engine query fails, the error is wrapped as 'get parent name'. The failure is reported back to the engine via fnCall.ReturnError.

Source

Thrown at cmd/codegen/generator/go/templates/modules.go:261

	defer telemetry.Close()

	// A lot of the "work" actually happens when we're marshalling the return
	// value, which entails getting object IDs, which happens in MarshalJSON,
	// which has no ctx argument, so we use this lovely global variable.
	setMarshalContext(ctx)

	fnCall := dag.CurrentFunctionCall()
	defer func() {
		if rerr != nil {
			if ` + voidRet + ` := fnCall.ReturnError(ctx, convertError(rerr)); err != nil {
				fmt.Println("failed to return error:", err, "\noriginal error:", rerr)
			}
		}
	}()

	parentName, err := fnCall.ParentName(ctx)
	if err != nil {
		return fmt.Errorf("get parent name: %w", err)
	}
	fnName, err := fnCall.Name(ctx)
	if err != nil {
		return fmt.Errorf("get fn name: %w", err)
	}
	parentJson, err := fnCall.Parent(ctx)
	if err != nil {
		return fmt.Errorf("get fn parent: %w", err)
	}
	fnArgs, err := fnCall.InputArgs(ctx)
	if err != nil {
		return fmt.Errorf("get fn args: %w", err)
	}

	inputArgs := map[string][]byte{}
	for _, fnArg := range fnArgs {
		argName, err := fnArg.Name(ctx)
		if err != nil {

View on GitHub (pinned to 82ba2681db)

Solutions

  1. Re-run the function through `dagger call` / `dagger run` so proper call metadata is provided to the runtime
  2. Check engine health (`dagger query` works) and restart the engine if the session dropped
  3. Align dagger CLI and Go SDK versions (re-run `dagger develop` after upgrading the CLI)
  4. Inspect the wrapped %w cause for the underlying GraphQL/transport error and act on it (e.g. connection refused -> ensure engine is running)

Example fix

// before
$ ./dagger/main  # run directly, no engine metadata

// after
$ dagger -m ./dagger call my-function
Defensive patterns

Strategy: try-catch

Validate before calling

// ensure the runtime is invoked inside a dagger session
if os.Getenv("DAGGER_SESSION_PORT") == "" && os.Getenv("_EXPERIMENTAL_DAGGER_CLI_BIN") == "" {
	log.Fatal("module runtime must be started via dagger call/run, not directly")
}

Try / catch

// in module code, errors are reported back to the engine automatically;
// verify by running and inspecting the returned error:
//   out, err := dag.Module().MyFn(ctx)
//   if err != nil { /* strings.Contains(err.Error(), "get parent name") */ }

Prevention

When it happens

Trigger: Executing a module function when the CurrentFunctionCall query to the Dagger engine fails or returns an error for ParentName — e.g. the invocation context is missing/corrupt (not run under `dagger call`), engine connection drops mid-call, or engine/SDK version skew makes the API field unavailable.

Common situations: Running the generated binary directly outside the dagger CLI without the call metadata; engine restarting/OOM during a call; mismatched dagger CLI vs SDK versions after upgrade; network/uds issues between module runtime and engine.

Related errors


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