Skip to content

fix(axum-macros): use OptionalFromRequest for Option<T> fields in derive#3665

Open
4Mathleu wants to merge 1 commit intotokio-rs:mainfrom
4Mathleu:fix/optional-from-request-3623
Open

fix(axum-macros): use OptionalFromRequest for Option<T> fields in derive#3665
4Mathleu wants to merge 1 commit intotokio-rs:mainfrom
4Mathleu:fix/optional-from-request-3623

Conversation

@4Mathleu
Copy link
Copy Markdown
Contributor

@4Mathleu 4Mathleu commented Feb 18, 2026

Motivation

Option<T> fields with #[from_request(via(...))] were using .ok() to convert any rejection into None, silently swallowing errors like invalid JSON.

Fixes #3623

Solution

Use OptionalFromRequest / OptionalFromRequestParts traits instead of .ok(), letting each extractor decide when to return None vs propagate an error.

Option<T> fields in #[derive(FromRequest)] and #[derive(FromRequestParts)]
now use OptionalFromRequest / OptionalFromRequestParts instead of calling
.ok() on the result. This lets each extractor decide when to return None
vs an error, instead of silently converting all rejections to None.

Fixes: tokio-rs#3623
@jplatte
Copy link
Copy Markdown
Contributor

jplatte commented Feb 18, 2026

What's with all the backslashes in the PR description?

@4Mathleu
Copy link
Copy Markdown
Contributor Author

What's with all the backslashes in the PR description?

Formatting got mangled when writing the description (also maybe translation shit)

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

Successfully merging this pull request may close these issues.

FromRequest derive with Option<T> field unexpected semantics

2 participants