docs(adr): spool arithmetic and the unbounded slow-drip limitation for the receive cap (#47)

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-03 21:12:48 +02:00
parent 145949875e
commit 4ef446548d
1 changed files with 9 additions and 0 deletions
@@ -1457,6 +1457,15 @@ an hour of Swedish *was* an unknown here; it is now measured, see decision 8.)
   perhaps one time in five at current volume). Jobs still queued at shutdown stay `queued` until
   the next start's sweep. The user re-uploads, with an honest message.
   *Receive limits (#47).* Request bodies are received at most 4 at a time, 2 per user, answered
   as busy beyond that. Together with the 20-job queue and the running job that bounds the spool
   at about (4 + 20 + 1) x 200 MiB = 5 GiB of the 6 Gi `emptyDir` (infra): raising any of those or
   `TAPIR_UPLOAD_MAX_BYTES` must revisit that sum (pinned by `TestNewIntake_Defaults...`, not
   enforced against infra). **A slow-drip body holds its slot without a time bound**: the server
   sets `ReadHeaderTimeout` only, because a `ReadTimeout` would cut legitimate 200 MiB uploads on
   slow links; two slow bodies take a user's two slots and two such users make everyone's upload
   busy. It needs a valid session; recorded as a limitation with a follow-up issue.
 8. **Chat reuses `chat.Service`; it is not forked.** The uploaded-transcript chat handlers
   look the row up through the RLS-scoped store, so a non-owner gets 404 by the same mechanism
   as ADR-027's summary gate, **before any model is called**. ADR-027's decisions (ephemeral,