8000 `default` tag causes panic with generic wrapper types (e.g., `OmittableNullable[string]`) · Issue #814 · danielgtaylor/huma · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

default tag causes panic with generic wrapper types (e.g., OmittableNullable[string]) #814

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
derkan opened this issue May 3, 2025 · 0 comments

Comments

@derkan
Copy link
derkan commented May 3, 2025

Hi 👋

While experimenting with the OmittableNullable[T] type as shown in the official examples/omit, I encountered a panic when trying to set a default value on a field of this type.

❗️ Problem

The following struct works fine:

type MyInput struct {
    Name OmittableNullable[string] `json:"name,omitempty" maxLength:"10"`
}

However, adding a default tag causes a runtime panic:

type MyInput struct {
    Name OmittableNullable[string] `json:"name,omitempty" maxLength:"10" default:"Kari"`
}

💥 Panic Trace

panic: unable to convert string to main.OmittableNullable[string] for field 'Name': schema is invalid
github.com/danielgtaylor/huma/v2.convertType(...)
	.../huma/v2@v2.32.0/schema.go:469 +0x3bc
...

⚠️ Root Cause

From what I can see in convertType() in schema.go, the default value "Kari" is treated as a string, but the target field type is OmittableNullable[string], a custom generic struct. Go's reflection system cannot convert between these types directly, which triggers the panic.

✅ Expected Behavior

Ideally, Huma should:

  • Detect when a field is a wrapper struct around a basic type, like OmittableNullable[string].
  • Allow setting a default tag for the inner value type (T), constructing a proper wrapper instance (e.g., OmittableNullable[string]{Value: "Kari", Present: true}).

💡 Possible Solutions

  • Introduce support for unwrapping known nullable/wrapper types when parsing defaults.
  • Optionally allow custom hooks or interfaces (e.g., FromDefault(value string) (any, error)) on field types to control how default values are constructed.

Let me know if a workaround is possible in the meantime — thank you for the great library!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant
0