ReplayRequest

The names of the product elements.

The name of the type.

Parses the query parameters, refusing anything out of bounds.

Out-of-range limits are refused, never clamped. An operator who asks to replay 500 records and is silently given 200 believes 500 events are back in the pipeline, and the 300 that are not get discovered by somebody else, later, from a gap in a dashboard. Refusing costs one more command and removes the whole failure class. The unspecified case is the one exception, and it is not clamping: nothing was asked for, so nothing is overridden.

refs and limit are alternatives rather than a conjunction: naming records explicitly is the bound, so a refs list is checked against maxRecords on its own and limit is ignored. Combining them would create a request whose meaning — "the first ten of these forty" — nobody would guess the same way twice.

The page size an unspecified request gets, capped by the ceiling. Small enough to read, large enough that the usual answer to "what is in the DLQ" needs one request.

What the routes pass when the caller supplied no limit.

A sentinel exists because a Cask annotation's default must be a compile-time constant, and the ceiling is configuration. With a literal default of 20 and a deployment that sets max-records = 5, every bare GET /admin/dlq/records would answer 400 forever — the request nobody supplies parameters to, refused for exceeding a limit nobody asked to exceed. Resolving "unspecified" here against the actual ceiling removes that whole class, and zero is a safe spelling for it: nobody meaningfully asks for no records.