Axum Code Review

Review Workflow

1. Check Cargo.toml — Note axum version (0.6 vs 0.7+ have different patterns), tower, tower-http features
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

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

Review Checklist

Routing

• Routes organized by domain (nested routers for

  /api/users

  ,

  /api/orders

  )
• Fallback handlers defined for 404s
• Method routing explicit (

  .get()

  ,

  .post()

  , not

  .route()

  with manual method matching)
• No route conflicts (overlapping paths with different extractors)

Extractors

• Body-consuming extractors (

  Json

  ,

  Form

  ,

  Bytes

  ) are the LAST parameter

• State<T>

  requires

  T: Clone

  — typically

  Arc<AppState>

  or direct

  Clone

  derive

• Path<T>

  parameter types match the route definition

• Query<T>

  fields are

  Option

  for optional query params with

  #[serde(default)]

• Custom extractors implement

  FromRequestParts

  (not body) or

  FromRequest

  (body)

State Management

• Application state shared via

  State<T>

  , not global mutable statics
• Database pool in state (not created per-request)
• State contains only shared resources (pool, config, channels), not request-specific data

• Clone

  derived or manually implemented on state type

Error Handling

• Handler errors implement

  IntoResponse

  for proper HTTP error codes
• Internal errors don't leak to clients (no raw error messages in 500 responses)
• Error responses use consistent format (JSON error body with code/message)

• Result<impl IntoResponse, AppError>

  pattern used for handlers

Middleware

• Tower layers applied in correct order (outer runs first on request, last on response)

• tower-http

  used for common concerns (CORS, compression, tracing, timeout)
• Request-scoped data passed via extensions, not global state
• Middleware errors don't panic — they return error responses

Severity Calibration

Critical

• Body extractor not last in handler parameters (silently consumes body, later extractors fail)
• SQL injection via path/query parameters passed directly to queries
• Internal error details leaked to clients (stack traces, database errors)
• Missing authentication middleware on protected routes

Major

• Global mutable state instead of

  State<T>

  (race conditions)
• Missing error type conversion (raw

  sqlx::Error

  returned to client)
• Missing request timeout (handlers can hang indefinitely)
• Route conflicts causing unexpected 405s

Minor

• Manual route method matching instead of

  .get()

  ,

  .post()

• Missing fallback handler (default 404 is plain text, not JSON)
• Middleware applied per-route when it should be global (or vice versa)
• Missing

  tower-http::trace

  for request logging

Informational

• Suggestions to use

  tower-http

  layers for common concerns
• Router organization improvements
• Suggestions to add OpenAPI documentation via

  utoipa

  or

  aide

Valid Patterns (Do NOT Flag)

• #[axum::debug_handler]

  on handlers — Debugging aid that improves compile error messages

• Extension<T>

  for middleware-injected data — Valid pattern for request-scoped values
• Returning

  impl IntoResponse

  from handlers — More flexible than concrete types

• Router::new()

  per module, merged in main — Standard organization pattern

• ServiceBuilder

  for layer composition — Tower pattern, not over-engineering

• axum::serve

  with

  TcpListener

  — Standard axum 0.7+ server setup

Before Submitting Findings

Load and follow

beagle-rust:review-verification-protocol

before reporting any issue.