axum-errors-extractor-rejections

What problem does it solve?

This Skill helps you control how Axum converts extractor failures into HTTP responses so clients get the right status codes and error bodies instead of default plain text or incorrect “invented” responses.

Core Features & Use Cases

• Custom rejection shaping for failed extractors: Replace the default plain-text rejection with a unified API error payload for Json, Path, Query, Form, and other built-in extractors.
• Safe, version-aware handling for Axum 0.7 vs 0.8: Prevent surprises from the Option<T> behavior change in Axum 0.8 by using the correct approach (Result<T, T::Rejection> when needed).
• Correct error mapping patterns: Use the recommended techniques—Result<Extractor, Rejection>, WithRejection, or #[derive(FromRequest)] with rejection(...)—while enforcing required rules like _ => catch-alls for #[non_exhaustive] enums and reusing rejection.status() / rejection.body_text().

Quick Start

Use the axum-errors-extractor-rejections skill to map a failing Json<T> extractor into a JSON API error response with the status and message derived from the rejection.