The receiver at /h/{uuid} has no MaxBodySize middleware, unlike the four admin page route groups, because its 1 MB body cap is enforced in the handler (Handlers.readWebhookBody). Nothing at the routing layer said so, so the omission read as forgotten. This takes the issue's second option: keep the cap in the handler and say so where the route is registered.
internal/server/routes.go: a comment at the /h/{uuid} registration says where the cap lives, why it is not MaxBodySize, and which test pins it.
internal/handlers/webhook.go: the readWebhookBody doc comment says it is the receiver's only body cap.
internal/server/routes_test.go: TestReceiver_OversizeBodyRefused posts a body of exactly 1 MB and one a byte over through the production router. The first is accepted; the second gets the handler's 413 and its message.
Why not the middleware: it would change what senders get. MaxBodySize answers a declared oversize body with its own text, and a chunked oversize body would reach the handler as a read error and get a 400 instead of a 413.
Judgement call: the test writes the cap as 1 << 20 rather than reading the handler's constant, which is unexported in another package, so changing the cap means changing the test too.
Judgement call: the request at exactly the cap is there so the test pins the cap's value, not only that some cap exists.
Model: opus-5-5
The receiver at `/h/{uuid}` has no `MaxBodySize` middleware, unlike the four admin page route groups, because its 1 MB body cap is enforced in the handler (`Handlers.readWebhookBody`). Nothing at the routing layer said so, so the omission read as forgotten. This takes the issue's second option: keep the cap in the handler and say so where the route is registered.
- `internal/server/routes.go`: a comment at the `/h/{uuid}` registration says where the cap lives, why it is not `MaxBodySize`, and which test pins it.
- `internal/handlers/webhook.go`: the `readWebhookBody` doc comment says it is the receiver's only body cap.
- `internal/server/routes_test.go`: `TestReceiver_OversizeBodyRefused` posts a body of exactly 1 MB and one a byte over through the production router. The first is accepted; the second gets the handler's 413 and its message.
Why not the middleware: it would change what senders get. `MaxBodySize` answers a declared oversize body with its own text, and a chunked oversize body would reach the handler as a read error and get a 400 instead of a 413.
Judgement call: the test writes the cap as `1 << 20` rather than reading the handler's constant, which is unexported in another package, so changing the cap means changing the test too.
Judgement call: the request at exactly the cap is there so the test pins the cap's value, not only that some cap exists.
Model: opus-5-5
/h/{uuid} has no MaxBodySize middleware, unlike the page route
groups; its cap is in the handler, which owns the 413 senders get.
A comment at the route registration now says so, and the handler's
read function notes it is the receiver's only body cap.
A new routing test sends a body exactly at the cap and one byte over
it through the production router, and checks the second is refused
with the handler's 413 and message.
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 receiver at
/h/{uuid}has noMaxBodySizemiddleware, unlike the four admin page route groups, because its 1 MB body cap is enforced in the handler (Handlers.readWebhookBody). Nothing at the routing layer said so, so the omission read as forgotten. This takes the issue's second option: keep the cap in the handler and say so where the route is registered.internal/server/routes.go: a comment at the/h/{uuid}registration says where the cap lives, why it is notMaxBodySize, and which test pins it.internal/handlers/webhook.go: thereadWebhookBodydoc comment says it is the receiver's only body cap.internal/server/routes_test.go:TestReceiver_OversizeBodyRefusedposts a body of exactly 1 MB and one a byte over through the production router. The first is accepted; the second gets the handler's 413 and its message.Why not the middleware: it would change what senders get.
MaxBodySizeanswers a declared oversize body with its own text, and a chunked oversize body would reach the handler as a read error and get a 400 instead of a 413.Judgement call: the test writes the cap as
1 << 20rather than reading the handler's constant, which is unexported in another package, so changing the cap means changing the test too.Judgement call: the request at exactly the cap is there so the test pins the cap's value, not only that some cap exists.
Model: opus-5-5
/h/{uuid} has no MaxBodySize middleware, unlike the page route groups; its cap is in the handler, which owns the 413 senders get. A comment at the route registration now says so, and the handler's read function notes it is the receiver's only body cap. A new routing test sends a body exactly at the cap and one byte over it through the production router, and checks the second is refused with the handler's 413 and message. Model: opus-5-5Review passed.
Model: opus-5-5
Re-gate passed on current next.
Model: opus-5-5