Currently, /audio and /ws accept files of any size with no upper bound. file.read() and websocket.receive_bytes() load the entire payload into memory before any validation happens, and filetype.guess() only checks MIME type — not size.
Risks
- A large upload (or many concurrent large uploads) can exhaust server RAM, especially since files are also written to
/dev/shm (tmpfs, itself RAM-backed) — a big-enough file could fill available memory twice over (once in the read buffer, once on tmpfs).
- Long transcription time for oversized audio ties up a worker/event-loop slot longer than expected, worsening the concurrency bottleneck already discussed for CPU-only deployment.
- No client feedback today — an oversized file just silently gets processed (or crashes) instead of a clear rejection.
Proposed Fix
Add a MAX_FILE_SIZE constant (e.g. 25 MB — reasonable upper bound for voice notes) and reject anything larger before writing to disk/tmpfs, returning a clear error response.
MAX_FILE_SIZE = 25 * 1024 * 1024 # 25 MB
For /audio:
byte = await file.read()
if len(byte) > MAX_FILE_SIZE:
return {"error": "File too large. Max size is 25MB."}
For /ws:
byte = await websocket.receive_bytes()
if len(byte) > MAX_FILE_SIZE:
await websocket.send_json({"error": "File too large. Max size is 25MB."})
continue
Note: this only rejects after the full payload is already read into memory — for stronger protection (rejecting before the full body is buffered), FastAPI/Starlette also support limiting via Content-Length header pre-check on /audio, or a reverse-proxy-level limit (e.g. nginx client_max_body_size) in front of both endpoints. Worth deciding whether app-level or proxy-level enforcement (or both) fits your deployment.
Acceptance Criteria
Currently,
/audioand/wsaccept files of any size with no upper bound.file.read()andwebsocket.receive_bytes()load the entire payload into memory before any validation happens, andfiletype.guess()only checks MIME type — not size.Risks
/dev/shm(tmpfs, itself RAM-backed) — a big-enough file could fill available memory twice over (once in the read buffer, once on tmpfs).Proposed Fix
Add a
MAX_FILE_SIZEconstant (e.g. 25 MB — reasonable upper bound for voice notes) and reject anything larger before writing to disk/tmpfs, returning a clear error response.For
/audio:For
/ws:Acceptance Criteria
/audioand/ws