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
- Align SDK and Dagger engine versions so the literal type is one both sides know
- Check the %T output in the message and verify whether it is a valid call.Literal type your Dagger version should support
- If you maintain custom literals, extend resultCallLiteralFromRecipeLiteral with a case for the type
- 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
- Keep SDK and engine versions in lockstep
- Never inject custom call.Literal implementations into core paths
- Pin Dagger CLI and SDK to compatible versions
- Regenerate SDKs after engine upgrades
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
- unknown DAG value type %T
- field %q: %w
- unknown result call literal kind %q
- failed parsing [%s], expected address format: [%s]
- use target SDK language: %s: %w
AI-assisted analysis of dagger/dagger@82ba2681db (2026-09-05).
Data as JSON: /api/errors/00a2e64f4d879dcf.
Report an issue: GitHub.