dagger/dagger · error

unsupported recipe input literal %T

Error message

unsupported recipe input literal %T

What it means

This error is returned by resultCallLiteralFromRecipeLiteral when the recipe literal's concrete type matches none of the supported call.Literal variants (null, bool, int, float, string, bytes, enum, digested string, ID, list, object). The %T verb prints the actual Go type, making this an internal invariant violation: a new call.Literal implementation was added without extending this conversion switch.

Source

Thrown at dagql/call_request_input.go:266

	case *call.LiteralObject:
		fields := make([]*ResultCallArg, 0, v.Len())
		for _, field := range v.Args() {
			converted, err := resultCallLiteralFromRecipeLiteral(ctx, field.Value(), memo)
			if err != nil {
				return nil, fmt.Errorf("field %q: %w", field.Name(), err)
			}
			fields = append(fields, &ResultCallArg{
				Name:        field.Name(),
				IsSensitive: field.IsSensitive(),
				Value:       converted,
			})
		}
		return &ResultCallLiteral{
			Kind:         ResultCallLiteralKindObject,
			ObjectFields: fields,
		}, nil
	default:
		return nil, fmt.Errorf("unsupported recipe input literal %T", lit)
	}
}

func resultCallArgFromInput(ctx context.Context, name string, input Input, sensitive bool) (*ResultCallArg, error) {
	if input == nil {
		return nil, fmt.Errorf("nil input for arg %q", name)
	}
	lit, err := resultCallLiteralFromInput(ctx, input)
	if err != nil {
		return nil, fmt.Errorf("arg %q: %w", name, err)
	}
	return &ResultCallArg{
		Name:        name,
		IsSensitive: sensitive,
		Value:       lit,
	}, nil
}

View on GitHub (pinned to 82ba2681db)

Solutions

  1. Align SDK and Dagger engine versions so the literal type is one both sides know
  2. Check the %T output in the message and verify whether it is a valid call.Literal type your Dagger version should support
  3. If you maintain custom literals, extend resultCallLiteralFromRecipeLiteral with a case for the type
  4. Report/upgrade if it is a core literal type — this indicates a missing conversion case
Defensive patterns

Strategy: try-catch

Validate before calling

switch lit.(type) {
case *call.LiteralNull, *call.LiteralBool, *call.LiteralInt, *call.LiteralFloat,
     *call.LiteralString, *call.LiteralBytes, *call.LiteralEnum,
     *call.LiteralDigestedString, *call.LiteralID, *call.LiteralList, *call.LiteralObject:
    // supported
default:
    return fmt.Errorf("unsupported literal %T", lit)
}

Type guard

func isSupportedLiteral(lit call.Literal) bool {
    switch lit.(type) {
    case nil, *call.LiteralNull, *call.LiteralBool, *call.LiteralInt,
        *call.LiteralFloat, *call.LiteralString, *call.LiteralBytes,
        *call.LiteralEnum, *call.LiteralDigestedString, *call.LiteralID,
        *call.LiteralList, *call.LiteralObject:
        return true
    }
    return false
}

Try / catch

if err != nil && strings.HasPrefix(err.Error(), "unsupported recipe input literal ") {
    // check SDK/engine version mismatch; upgrade the older side
}

Prevention

When it happens

Trigger: A *call.Argument's Value() returns a call.Literal implementation not covered by the switch — typically a newly added literal type from a newer engine while the conversion code is older, or a custom literal type injected in tests.

Common situations: SDK/engine version mismatch during upgrades; custom dagql extensions implementing call.Literal; corrupted or hand-crafted call IDs whose literal bytes deserialize into an unexpected type.

Related errors


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