fix(showcase): avatar upload rejected real photos (4 MiB → 10 MiB) + core regression test#106
Merged
Merged
Conversation
The showcase avatar upload "didn't work" for normal photos: maxUpload was 4 MiB, but typical phone photos are 3-8+ MiB, so MaxBytesReader returned a bare 413 "request too large" page on a full-page form submit — looking like the upload silently failed. Confirmed against the running instance: a 5 MiB multipart POST to /_action/Upload → 413; a sub-limit body gets past the size gate. Raise the cap to 10 MiB and state the limit in the form hint. via core was correct — the file-binding + plain-form-POST + http.Redirect(303) path works. Added a root regression test (TestUpload_plainFormPostBindsFileAnd ReturnsHandlerRedirect) that reproduces the showcase contract end-to-end: a multipart <form> POST with via_tab as a form field binds the via.File and the handler's 303 reaches the client unmangled (Via must not overwrite it with a datastar/200 action response).
joaomdsg
added a commit
that referenced
this pull request
Jun 10, 2026
#107) An action POST exceeding the body cap (WithMaxRequestBody/WithMaxUploadSize) trips MaxBytesReader before any action handler runs, so the only way to turn the bare 413 "request too large" page into something friendly is a framework hook. WithRequestTooLarge(h http.Handler) installs one (mirrors WithNotFound); default behavior — a plain 413 — is unchanged. Wire it in the showcase: a too-large avatar now bounces back to /app/profile with a flag the page renders as an inline "image was over 10 MB" message via a query-bound field, instead of dead-ending on a 413. Closes the T9-UX-413 follow-up to the avatar-upload fix (#106). Root build + tests green under -race; viashowcase builds/vets/tests green.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Symptom
Avatar upload "didn't work" on the showcase for normal photos.
Root cause
The showcase set
maxUpload = 4 MiB, but typical phone photos are 3–8+ MiB. The multipartMaxBytesReadertrips during parse and returns a bare413 "request too large"— and because the avatar form is a full-page<form>submit (not a datastar fetch), the browser just navigates to that 413 page, so it looks like the upload silently failed.Confirmed against the running instance:
/_action/Upload→ 413via_tab)Fix
maxUpload4 MiB → 10 MiB (comfortably fits a full-res photo).via core was correct
The file-binding + plain-
<form>POST +http.Redirect(303)path works as intended — it was the showcase's chosen limit that was too low. Added a root regression test (TestUpload_plainFormPostBindsFileAndReturnsHandlerRedirect) that reproduces the exact showcase contract end-to-end: a multipart<form>POST carryingvia_tabas a form field binds thevia.File, and the handler's 303 reaches the client unmangled (Via must not clobber it with a datastar/200 action response).(Separately tracked in
critique-council.md:T9-UX-413— oversize uploads should fail with a friendly in-form message rather than a bare 413; that's a framework-level change.)