axum-code-review

Axum Code Review

Review Workflow

1. Check Cargo.toml — Note axum version (0.6 vs 0.7+ have different patterns), Rust edition (2021 vs 2024), tower, tower-http features. Edition 2024 changes RPIT lifetime capture in handler return types and removes the need for async-trait in custom extractors.
2. Check routing — Route organization, method routing, nested routers
3. Check extractors — Order matters (body extractors must be last), correct types
4. Check state — Shared state via State<T>, not global mutable state
5. Check error handling — IntoResponse implementations, error types

Gates (before reporting findings)

Run in order. Do not write a finding until the step that applies has passed.

1. Version and edition on disk — Pass when: You have read the relevant Cargo.toml (crate or workspace root) and can state axum (and related tower/tower-http) versions and Rust edition. Then apply 0.6 vs 0.7+ or Edition 2024–specific checklist items only when that file supports them.

2. Per-finding evidence — Pass when: Each issue cites [FILE:LINE] from the current tree for the handler, router, layer, or type under review (not from memory, docs-only, or another branch).

3. Category check vs protocol — Pass when: For the finding type (routing conflict, extractor order, error leak, middleware order, etc.), you ran the matching checks from the review-verification-protocol skill (e.g. full handler signature for extractor order; surrounding error mapping before “raw error to client”). Then add the finding.

4. Output shape — Pass when: The report lines match Output Format below (severity + description).

Output Format

Report findings as:

[FILE:LINE] ISSUE_TITLE
Severity: Critical | Major | Minor | Informational
Description of the issue and why it matters.

Quick Reference

Issue Type	Reference
Route definitions, nesting, method routing	references/routing.md
State, Path, Query, Json, body extractors	references/extractors.md
Tower middleware, layers, error handling	references/middleware.md