The login form and the webhook create and edit forms, when shown again with an error, called WriteHeader with their 400 or 409 before renderTemplate. That committed the status before rendering started, so if the page's template failed, the answer was the error page under that 400 or 409, never a 500.
renderTemplateStatus takes the status and writes it only after the page has rendered into the buffer. renderTemplate keeps its signature and sends 200 through it. Each handler that set a status first now passes it instead, and no handler calls WriteHeader before a render.
Two tests use the login form with empty fields. One checks that the page still answers 400 with the whole page. The other checks that a login template failing partway through answers 500 with the error page and none of the form page.
Not visible in the diff: ordinary pages now write their 200 explicitly instead of on the first write, which behaves the same. On the form-error paths, the Content-Type header used to be set after the status had gone out, so it never reached the response and the server guessed the type from the body. It now arrives as set.
Deviation: the issue lists five call sites. next now has a sixth, the 409 on the edit form when an archive name is taken, and this PR covers it too.
Partially verified: the tests drive only the login form. The webhook form paths use the same helper but have no tests of their own.
Model: opus-5-5
The login form and the webhook create and edit forms, when shown again with an error, called `WriteHeader` with their 400 or 409 before `renderTemplate`. That committed the status before rendering started, so if the page's template failed, the answer was the error page under that 400 or 409, never a 500.
`renderTemplateStatus` takes the status and writes it only after the page has rendered into the buffer. `renderTemplate` keeps its signature and sends 200 through it. Each handler that set a status first now passes it instead, and no handler calls `WriteHeader` before a render.
Two tests use the login form with empty fields. One checks that the page still answers 400 with the whole page. The other checks that a login template failing partway through answers 500 with the error page and none of the form page.
Not visible in the diff: ordinary pages now write their 200 explicitly instead of on the first write, which behaves the same. On the form-error paths, the `Content-Type` header used to be set after the status had gone out, so it never reached the response and the server guessed the type from the body. It now arrives as set.
- Deviation: the issue lists five call sites. `next` now has a sixth, the 409 on the edit form when an archive name is taken, and this PR covers it too.
- Partially verified: the tests drive only the login form. The webhook form paths use the same helper but have no tests of their own.
Model: opus-5-5
The login form and the webhook create and edit forms set their 400 or
409 with WriteHeader before calling renderTemplate, so a template
failure there answered with that status instead of 500. A variant of
renderTemplate now takes the status and writes it only once the page
has rendered into the buffer; renderTemplate sends 200 through it.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The login form and the webhook create and edit forms, when shown again with an error, called
WriteHeaderwith their 400 or 409 beforerenderTemplate. That committed the status before rendering started, so if the page's template failed, the answer was the error page under that 400 or 409, never a 500.renderTemplateStatustakes the status and writes it only after the page has rendered into the buffer.renderTemplatekeeps its signature and sends 200 through it. Each handler that set a status first now passes it instead, and no handler callsWriteHeaderbefore a render.Two tests use the login form with empty fields. One checks that the page still answers 400 with the whole page. The other checks that a login template failing partway through answers 500 with the error page and none of the form page.
Not visible in the diff: ordinary pages now write their 200 explicitly instead of on the first write, which behaves the same. On the form-error paths, the
Content-Typeheader used to be set after the status had gone out, so it never reached the response and the server guessed the type from the body. It now arrives as set.nextnow has a sixth, the 409 on the edit form when an archive name is taken, and this PR covers it too.Model: opus-5-5
Review passed.
Model: opus-5-5
Re-gate passed on current next.
Model: opus-5-5