- Shipped
- August 8, 2026 at 4:51 AM UTC
- Author
- kamo
- Commit
- d6293c4
THE cause of the failing 3 GiB attachments, and it was ours, not the network. **************** was '500mb'. It is not a rewrite/middleware setting: Next wraps EVERY request body in a cloneable body capped at this value, route handlers included. At 524,288,000 bytes the cap was also silent — the body stream simply ended, with no error raised anywhere. The proxy forwarded 524,262,252 of a declared 2,181,048,727 bytes and MediaService then waited for a remainder that was never coming, which is why this presented for three rounds as a stalled connection and sent me chasing timeouts through Traefik, Node and Tomcat. The byte accounting added last round is what finally named it: two attempts stopping within 26 KB of the same round number is a limit, not a network. Raised to 3200mb — above the 3 GiB ceiling, below MediaService's own 3100MB request limit, so anything genuinely oversized is refused there with a clear 413 rather than truncated here. serverActions.bodySizeLimit stays at 500mb; attachments do not travel that path and no action should be entitled to gigabytes. Also locks the composer while a message is going out. A send captures the text and attachments as they stood when it started, so anything typed during a multi-minute upload was silently dropped when the draft reset. The text box, emoji, attach button and paste/drop are all disabled until it lands or is cancelled, with Cancel remaining available in the upload panel throughout.