- Shipped
- August 11, 2026 at 4:21 PM UTC
- Author
- kamo
- Commit
- f1de4ec
The backend now streams to 3 GiB, but three things in the browser and the BFF made that unreachable, each fatal on its own. The upload proxy did `await request.formData()`, pulled the file out, and rebuilt a second FormData to forward — the entire upload in this process's heap, twice. It now pipes the body straight through with node:http, the same construction the chat-attachment proxy already uses to carry 3 GiB in production. node:http rather than fetch because undici applies a 300s headers timeout to every request, and a multi-gigabyte upload spends far longer than that on the wire before ConversionService — which hashes the spooled file before answering — can reply; with fetch, the proxy rather than the product would decide the maximum file size. computeBlake3(file) and computeSha3256(file) each call file.arrayBuffer(), and the uploaders ran them in a Promise.all, so the file was fully resident in the tab TWICE at peak. At the old 500MB cap that was already a gigabyte of tab memory; at 3 GiB it is six and the tab dies before a byte is uploaded. Replaced with computeFileDigests, which walks the file once in 4 MiB slices and feeds both hashers from the same chunk — peak memory is one chunk at any size, mirroring HashUtils.computeDigests on the server. Both digests are still computed because the upload endpoint recomputes and compares both; js-sha3 is pure JavaScript and dominates the time, which is the price of the stronger server-side check, so hashing now reports progress rather than sitting at 2% for minutes. MultiFileUploader had no size limit at all, so an oversize pick spent minutes hashing to earn an opaque failure. Size is now checked before anything reads the file, and the file is added in the error stage naming both its size and the limit.