Constant DEFAULT_BODY_LIMIT_BYTES 

pub const DEFAULT_BODY_LIMIT_BYTES: usize = _; // 2_097_152usize

Default request body limit (bytes) for the generated router() / rpc_router() entry points, applied via axum::extract::DefaultBodyLimit::max(body_limit_bytes).

Set to 2 MiB specifically because that’s axum’s own implicit default already — axum::body::Bytes’s FromRequest impl (and everything built on it: String, Json, Form) refuses bodies over 2 MiB out of the box, with no layer required at all, verified against the vendored axum-core 0.5.6 this workspace’s Cargo.lock actually pins (its own doc comment: “For security reasons, Bytes will, by default, not accept bodies larger than 2MB”). Every generated handler extracts Bytes, so request bodies were already implicitly capped at 2 MiB before this constant existed — the gap #413 closes is that this limit was invisible, undocumented, and not expressed anywhere in cratestack’s own code, not that a limit was absent.

Matching that number rather than picking a smaller, “more considered” one makes this constant — and the DefaultBodyLimit layer built from it — provably a no-op on upgrade: naming, documenting, and making overridable a limit that was already there, instead of silently tightening what an existing deployment can send. An earlier revision of this constant used 1 MiB; that was reverted once docs/design/request-response-size-bounds.md’s Decision 2 (written independently, without knowledge of that choice) made the “match axum’s own default” argument explicit — see that section for the full reasoning and the empirical check that BATCH_MAX_ITEMS (1000 frames) still fits comfortably inside a 2 MiB request at any realistic average frame size.

A deployment that legitimately needs to accept larger bodies passes a bigger value to router(..., body_limit_bytes) / rpc_router(..., body_limit_bytes) — every generated entry point takes this as an explicit, real parameter (see this module’s doc comment for why that, and not re-layering, is the supported override mechanism).