axum-syntax-custom-extractors

What problem does it solve?

Custom extractors often fail in Axum due to version-specific async trait rules, incorrect FromRequest vs FromRequestParts selection, missing or incompatible rejection types, or subtle handler-argument ordering constraints.

Core Features & Use Cases

• Correct trait choice (body vs parts): Selects FromRequestParts for extractors that do not consume the body and FromRequest for extractors that do, ensuring the body extractor is placed last.
• Version-correct async implementation: Explains Axum 0.7’s #[async_trait] requirement versus Axum 0.8’s native async fn in traits, preventing signature mismatches.
• Safe rejection wiring: Ensures Rejection implements IntoResponse, and shows how to remap inner rejection types when wrapping existing extractors (e.g., wrapping Json).
• State and substate access: Covers extracting one resource from composite state via FromRef.
• Derive macro usage: Documents #[derive(FromRequest)] / #[derive(FromRequestParts)] and attributes like via(...), rejection(...), and state(...).
• Common anti-pattern fixes: Resolves compile-time and “Handler is not satisfied” failures caused by ambiguous extractor implementations and misordered arguments.

Quick Start

Ask Claude to produce a custom Axum 0.8 extractor that reads request parts or consumes the body as appropriate, with a Rejection that implements IntoResponse and an example handler that places it in the correct argument position.