Form-error paths commit a 4xx before rendering, so a failed render there cannot report 500 #128

New Issue

2026-08-12T11:46:09+02:00

clawbot commented

2026-08-12 11:46:09 +02:00

Found while fixing #123, out of that issue's scope.

renderTemplate now buffers, so a mid-render failure never ships a partial body and can serve a real 500. Five call sites defeat the status half of that, because they call w.WriteHeader before renderTemplate:

internal/handlers/auth.go renderLoginError
internal/handlers/source_management.go, four form-validation branches (missing name, bad retention on create, and the two matching branches on edit)

On those paths the status is already committed when rendering starts, so a template failure yields the pre-set 400 with an Internal server error body rather than a 500. The body is honest and carries no part of the aborted page; only the status is wrong.

Severity is low: it only shows up when a form-error page's own template fails. The fix is to let the render path carry the intended status and write the header after a successful render, e.g. a renderTemplateStatus(w, r, page, data, status) variant that the plain helper delegates to with 200.

Definition of done

No handler calls WriteHeader before renderTemplate.
A form-error page still responds 400 with its rendered body.
A failing template on a form-error path responds 500 with no partial body.

Found while fixing https://git.eeqj.de/sneak/webhooker/issues/123, out of that issue's scope. `renderTemplate` now buffers, so a mid-render failure never ships a partial body and can serve a real 500. Five call sites defeat the status half of that, because they call `w.WriteHeader` before `renderTemplate`: - `internal/handlers/auth.go` `renderLoginError` - `internal/handlers/source_management.go`, four form-validation branches (missing name, bad retention on create, and the two matching branches on edit) On those paths the status is already committed when rendering starts, so a template failure yields the pre-set 400 with an `Internal server error` body rather than a 500. The body is honest and carries no part of the aborted page; only the status is wrong. Severity is low: it only shows up when a form-error page's own template fails. The fix is to let the render path carry the intended status and write the header after a successful render, e.g. a `renderTemplateStatus(w, r, page, data, status)` variant that the plain helper delegates to with 200. ## Definition of done - No handler calls `WriteHeader` before `renderTemplate`. - A form-error page still responds 400 with its rendered body. - A failing template on a form-error path responds 500 with no partial body.

clawbot referenced this issue

2026-08-12 11:46:33 +02:00

Render templates via a buffer, not the ResponseWriter (closes #123) #131

clawbot referenced this issue

2026-08-12 11:46:43 +02:00

renderTemplate streams to the ResponseWriter, so a mid-render template error ships a partial page #123

clawbot referenced this issue

2026-08-12 11:55:46 +02:00

Render templates via a buffer, not the ResponseWriter (closes #123) #131

clawbot referenced this issue

2026-08-17 23:50:35 +02:00

Milestone 1.0.0: internet-facing readiness #111