1.8 KiB
| title | status | type | priority | created_at | updated_at |
|---|---|---|---|---|---|
| Raise per-file upload limit to 32 MiB for large wasm binaries | completed | task | high | 2026-07-21T17:17:56Z | 2026-07-21T17:18:42Z |
User's optimized bin_bg.wasm is 22 MiB, exceeding the 16 MiB per-file cap ("exceeds the maximum per-file size of 16777216 bytes"). A .tar.zst upload decoded fine within the Worker CPU budget (zstd is fast) and correctly hit the per-file limit; the earlier 503 was an xz attempt killed by exceededCpu (lzma-rs too slow in wasm) — zstd is the codec that works.
Change: bump ONLY max_file 16 -> 32 MiB. Keep max_uncompressed_total (48 MiB) and max_compressed / MAX_UPLOAD_BYTES (24 MiB) unchanged — they already fit a 22 MiB wasm + zst-compressed body, and keeping them bounds worst-case Worker memory (body + decompressed manifest) safely under the ~128 MiB isolate ceiling. 32 < 48 keeps per-file < total.
Spots: core/upload.rs UploadLimits::default (value + doc comment); design doc §2.2 number. No frontend/api.rs/body-cap change needed (per-file error is server-side only).
Known latent issue (out of scope, note for follow-up): the xz path can still 503 via exceededCpu on large files because lzma-rs is slow in wasm. Fine as long as users pick zstd/gzip.
Then: validate (all six), commit, push, deploy.
Summary of Changes
Bumped max_file 16 to 32 MiB in UploadLimits::default (fits the user 22 MiB bin_bg.wasm with headroom). Left max_uncompressed_total (48 MiB) and max_compressed / MAX_UPLOAD_BYTES (24 MiB) unchanged so worst-case Worker memory (buffered body + decompressed manifest = 24+48) stays safely under the ~128 MiB isolate ceiling. Updated the default() doc comment and design doc §2.2. zstd is the working codec; xz still risks an exceededCpu 503 on large files (lzma-rs slow in wasm) — noted for follow-up. Validation green: 196 unit + 20 doctests.