-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Closed
Labels
Milestone
Description
- I have looked for existing issues (including closed) about thisTo pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
Bug Report
Version
0.8.1
Crates
axum-macros
Description
https://docs.rs/axum/latest/axum/extract/derive.FromRequest.html#the-whole-type-at-once claims that:
The rejection will be the “via extractors”’s rejection. For the previous example that would be axum::extract::rejection::ExtensionRejection.
but from what I've found, this is incorrect. I've tried to use #[from_request(via(Query))]
on a struct, assuming that the corresponding rejection would be QueryRejection
, but instead axum::response::Response
was put in the derived impl (documented as the default at https://docs.rs/axum/0.8.1/axum/extract/derive.FromRequest.html#the-rejection).
I assume that this is a bug in the derive macro for at least FromRequestParts
, but probably FromRequest
too.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
kyle-nweeia commentedon Mar 3, 2025
@Turbo87 could you provide an example of an extractor and a handler that cause the wrong rejection to be used?
Turbo87 commentedon Mar 9, 2025
I think this is roughly what I did back then:
if I use
#[from_request(via(Query), rejection(QueryRejection))]
instead it works, but not without it. this makes it difficult to use the additional information inQueryRejection
in a custom HTTP response.axum::response::Response
#3261kyle-nweeia commentedon Mar 26, 2025
@Turbo87 do you think that #3261 will solve the problem?