feat(0119): reject every invalid input with a 400 envelope

[stkrolikiewicz]

Summary

• Custom ValidatedQuery/ValidatedJson/ValidatedPath extractors route every axum rejection through the standard ErrorEnvelope — the old text/plain 400/415/422 bodies are gone; 400s now carry Cache-Control: no-store, and POST /prices/batch gets an explicit 16 KB body limit
• Query params are typed serde enums (the six stringly parse_* fns deleted): unknown tokens 400 with the valid values enumerated, search is capped at 1–12 ASCII alphanumerics, and the same enums publish into OpenAPI (contract-tested — the test caught dangling $refs utoipa-axum does not auto-register)
• Pagination cursor: deny_unknown_fields, 256-char token cap, and payload type-checked against the active sort — closes a client-reachable 500 (corrupt v reaching ClickHouse toFloat64)
• OHLCV: real date parsing (chrono, already in the build graph) with validated epochs bound via toDateTime(?), plus an explicit window rule (start < end, ≤5000 points at the chosen granularity) replacing silent truncation; the timeframe window anchors to end when only end is given
• 43 new CH-less negative tests drive the real router with AppState::without_ch() (panics on any CH access, proving validation precedes every query) and run in the existing CI cargo test step; prices-api added to the clippy -D warnings gate; all 21 live-CH integration tests pass against the prod-pinned 26.3.10.60

Task: lore/1-tasks/active/0119_FEATURE_api-input-validation-hardening.md (param → rule → error-code table + recorded policies)

[karczuRF]

Review notes — input-validation hardening

Reviewed origin/develop...origin/feat/0119_api-input-validation-hardening (23 files, +1183/−219). CI green on all three jobs.

The plumbing looks correct: the ValidatedQuery/ValidatedJson/ValidatedPath extractors, the enum-ised param parsers, the cursor deny_unknown_fields + valid_for type check, and the epoch-clamping of start/end all hold up — no unsound SQL bind, no missing await, no dropped error path, no reachable panic.

Everything below is the same shape instead: a validation rule stricter than the data model it guards, so requests that worked before now return 400.

---

1. ?search rejects asset-code prefixes the API itself can address — packages/prices-api/src/assets/handlers.rs:199

The rule requires every byte of search to be is_ascii_alphanumeric(). But classic asset codes are 4/12 raw bytes off the ledger, decoded with String::from_utf8_lossy(...) in packages/prices-ingest-core/src/canonical.rs:27, and AssetIdentifier::parse (identity.rs:53) imposes no charset restriction on the code half of CODE:ISSUER.

This PR's own common/cursor.rs:22-26 comment argues the opposite for the same data:

the DB legitimately holds empty codes (Soroban rows) and lossy-decoded on-chain garbage, so the only safe rule here is a length cap — any charset restriction would 400 a cursor the API itself just issued.

An asset whose on-chain code contains ., -, a space or a replacement char is fetchable via GET /v1/assets/{code}:{issuer} and appears in GET /v1/assets, but ?search=<its prefix> now 400s instead of returning it. A length cap alone — matching the cursor decision — is the consistent rule.

2. start == end is rejected although the SQL bounds are inclusive — handlers.rs:367

if eff_start >= eff_end 400s a zero-span window, but the very next block reasons that a zero-span window is legitimate: points = ceil(span/g) + 1 deliberately counts one bucket for span == 0 ("the SQL bounds are inclusive on both ends").

?start=2026-06-15&end=2026-06-15&granularity=1d — the natural way to ask for one day's candle — returned that candle before this PR (>= midnight AND <= midnight) and now returns 400 start must be before end. The guard wants to be eff_start > eff_end.

3. Granularity still defaults from timeframe on an explicit window, so plain ?start= 400s — handlers.rs:322

granularity falls back to timeframe.default_granularity(), and timeframe falls back to H24 → 15m, regardless of whether start/end were supplied.

GET /v1/assets/native/ohlcv?start=2020-01-01 (no timeframe, no granularity) computes ~231,000 points at 15m and returns 400 telling the caller to pick a coarser granularity — for a request that carried no granularity and no timeframe at all. Before this PR it returned the newest 5000 15m candles. When start/end are explicit, the auto-granularity should come from the actual window width, not from a timeframe the caller never asked for.

4. +HH:MM offsets are unreachable over HTTP, and replacen guarantees the failure — handlers.rs:528

parse_time's unit test asserts "2026-06-15T11:30:00+0200" and "2026-06-15T11:30+02:00" parse. In a real query string + decodes to a space, so the handler receives 2026-06-15T11:30:00 02:00; s.contains(' ') is then true and replacen(' ', "T", 1) rewrites it to 2026-06-15T11:30:00T02:00, which every parser below rejects → 400 invalid start.

So curl '.../ohlcv?start=2026-06-15T11:30:00+02:00' (or any client that does not percent-encode +) is refused for a value the docstring and OpenAPI description advertise as accepted. The unit tests pass the string straight to parse_time, so they can't catch this, and none of the 43 new router-level tests cover an offset form.

5. Issued cursors are not URL-safe, so echoing next_cursor verbatim can 400 — common/cursor.rs:54

encode uses base64::engine::general_purpose::STANDARD, which emits +, / and =. A client that appends the next_cursor from the response body to ?cursor= without percent-encoding turns + into a space, decode fails, and pagination dies with 400 invalid cursor mid-walk. tests/list.rs:98-105 works around exactly this (.replace('+', "%2B")), which is evidence the shape is already known. URL_SAFE_NO_PAD on both encode and decode removes the footgun; the 256-char cap and deny_unknown_fields added here don't address it.

6. The "start must be before end" message names a parameter the client never sent — handlers.rs:360

With ?start=2099-01-01 and no end, eff_end is now, the guard trips, and the caller is told start must be before end for a param they never supplied. tests/ohlcv.rs::ohlcv_future_start_without_end_is_400 locks in the status but not the message. A distinct "start is in the future" saves a support round-trip.

7. timeframe=all at its own default granularity will start returning 400 around 2029-06 — handlers.rs:374

Genesis (1_443_571_200) → now at 1d is ~3,976 points today and grows 365/yr; it crosses OHLCV_MAX_POINTS = 5000 in mid-2029, at which point the bare GET .../ohlcv?timeframe=all — the documented default for that timeframe — hard-400s with no client change. The task file records this deliberately ("Time bomb, on purpose"), so this is for visibility rather than as an oversight: defaulting All to 1w in Timeframe::default_granularity removes the cliff at no cost.

---

Checked and cleared

• Bind ordering in list_assets/ohlcv still matches placeholder order after the since_interval removal; toDateTime(?) receives an i64 clamped to 0..=4_102_444_800, inside ClickHouse DateTime range — the parseDateTimeBestEffort → 500 path is genuinely closed.
• points can never under-count actual buckets (ceil(span/g)+1 >= floor(end/g)−ceil(start/g)+1 for every aligned grain, and 1M at 30 d over-counts), so silent truncation can't slip back through the check.
• Cursor::valid_for(true) requiring a finite f64 does close the toFloat64 500; u32 on id rejects negatives in serde.
• DefaultBodyLimit::max on the batch router survives .nest("/v1", …) and the outer portal/auth layers (inner layer inserts the extension last, closest to the handler).
• chrono adds no new packages to Cargo.lock beyond the prices-api dep edge, so clock was already resolved — the "compiles nothing new" claim holds.