fix: raise the upload ceiling to a true 1 MB #8

Merged

iec-admin merged 1 commit from claw/upload-1mb-e5a9 into main

2026-09-11 23:24:14 +00:00

iec-admin commented

2026-09-11 23:24:10 +00:00

Contributor

Closes #7.

The 900 KB budget assumed multipart overhead needed real headroom under the 1 MB ingress cap. Measured against production, the envelope is ~200 bytes — so 148 KB was being left unused and videos were rejected at 0.9 MB that would have gone through.

Budget is now MAX_REQUEST_BYTES - 2048 = 1,046,528 bytes, which displays as "1.0 MB".

Also bounds the fallback <img> decode at 20s. It settled only on onload/onerror, so a load doing neither would hang the uploader on Preparing… indefinitely.

Verified through the admin UI

Case	Result
Video 1,040,000 B (just under)	uploads — was blocked before
Video 1,200,000 B (over)	blocked client-side: "Video is 1.1 MB … the upload limit is 1.0 MB"
12 MB photo (worst case)	uploads — 1497×1122, up from 1404×1053

Ingress cutoff measured directly against prod: 1,048,576 B → 413; 1,048,300 B → 401.

type-check and build clean.

Not fixed by this

A large hero video still can't be uploaded — 1 MB is the hard ingress ceiling and video can't be re-encoded in a canvas. That needs nginx.ingress.kubernetes.io/proxy-body-size raised on the ingress.

🤖 Generated with Claude Code

Closes #7. The 900 KB budget assumed multipart overhead needed real headroom under the 1 MB ingress cap. Measured against production, the envelope is ~200 bytes — so 148 KB was being left unused and videos were rejected at 0.9 MB that would have gone through. Budget is now `MAX_REQUEST_BYTES - 2048` = **1,046,528 bytes**, which displays as "1.0 MB". Also bounds the fallback `<img>` decode at 20s. It settled only on `onload`/`onerror`, so a load doing neither would hang the uploader on `Preparing…` indefinitely. ## Verified through the admin UI | Case | Result | |---|---| | Video 1,040,000 B (just under) | **uploads** — was blocked before | | Video 1,200,000 B (over) | blocked client-side: *"Video is 1.1 MB … the upload limit is 1.0 MB"* | | 12 MB photo (worst case) | uploads — 1497×1122, up from 1404×1053 | Ingress cutoff measured directly against prod: 1,048,576 B → `413`; 1,048,300 B → `401`. `type-check` and `build` clean. ## Not fixed by this A large hero video still can't be uploaded — 1 MB is the hard ingress ceiling and video can't be re-encoded in a canvas. That needs `nginx.ingress.kubernetes.io/proxy-body-size` raised on the ingress. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

iec-admin added 1 commit

2026-09-11 23:24:10 +00:00

fix: raise the upload ceiling to a true 1 MB (#7 ) 8462ef2c15

The budget was set to 900 KB on the assumption that the multipart envelope
needed real headroom under the ingress cap. Measured against production it is
about 200 bytes: 1,048,576 bytes is refused, 1,048,300 is accepted. That left
148 KB of usable room unused and rejected videos at 0.9 MB that would have
gone through.

Derive the budget as MAX_REQUEST_BYTES minus a 2 KB allowance — an order of
magnitude more than measured, enough for any realistic filename — so the limit
a person sees is 1.0 MB. Photos gain from the same change, holding more
resolution now the compressor has more room to work in: the worst-case test
image lands at 1497x1122 rather than 1404x1053.

Also bound the fallback <img> decode. It settled only on load or error, so a
load doing neither would leave the uploader on "Preparing…" with nothing to
time it out. It now fails after 20s as an ordinary upload error.

This does not make a large hero video uploadable — 1 MB is the ingress ceiling
and video cannot be re-encoded in a canvas. Raising proxy-body-size on the
ingress is the only fix for that.

close #7

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>