Cap bulk zip downloads at 50 documents to prevent in-memory exhaustion
bmersereau proposed a hard ceiling on the bulk zip download route: requests for more than 50 documents get a 400, preventing an authenticated user from triggering simultaneous in-memory loading of an unbounded file set. The PR is open.
The documents route gains a constant for the maximum document count and a guard that returns 400 before any S3 fetches begin if the request exceeds it. The limit is named rather than inlined, which makes it easy to adjust.
The approach is deliberately minimal. Rather than streaming the zip or restructuring how documents are loaded into memory, bmersereau picks a fixed cap and rejects oversized requests outright. That's a quick, auditable guarantee against the specific exhaustion vector - one authenticated call spinning up 200+ concurrent in-memory file loads - without restructuring the route.
A vitest configuration scopes test discovery to the source tree, excluding compiled output. A static-analysis test asserts the limit constant continues to exist. The backend package.json gains a test script so the suite can be invoked directly. Two tracked issues are claimed as closed.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?