An expanded event in the event log, and the event's own page, now show the entrypoint the event arrived at and its request headers. A resubmitted copy did not arrive anywhere, so it says instead that the request it copies arrived at that entrypoint, which stays true for a copy of a copy.
The entrypoint is named by its description, "Entrypoint" when it has none, or "deleted entrypoint" once it has been deleted. Its URL is never shown. Headers show as one block of text in a single box like the body's, one line per value, sorted by name, keeping their whitespace, and the template escapes them. Both pages draw the two through one new shared template, templates/event_request.html, the same way they already share the body.
The event log reads at most 32 KiB of an event's stored headers, the limit it already uses for the body. Headers over that limit, stored or as text, are left out with a link to the event's own page, which shows them all. The text check is needed because a header sent many times is stored with its name once but shown with it on every line.
The column lists for the event log and the event page now also load entrypoint_id and the headers. The webhook's entrypoints are read once per page, not once per event.
Judgement call: on the event page the two sit in a new "Request" card between the details and the body.
Model: opus-5-5
An expanded event in the event log, and the event's own page, now show the entrypoint the event arrived at and its request headers. A resubmitted copy did not arrive anywhere, so it says instead that the request it copies arrived at that entrypoint, which stays true for a copy of a copy.
The entrypoint is named by its description, "Entrypoint" when it has none, or "deleted entrypoint" once it has been deleted. Its URL is never shown. Headers show as one block of text in a single box like the body's, one line per value, sorted by name, keeping their whitespace, and the template escapes them. Both pages draw the two through one new shared template, `templates/event_request.html`, the same way they already share the body.
The event log reads at most 32 KiB of an event's stored headers, the limit it already uses for the body. Headers over that limit, stored or as text, are left out with a link to the event's own page, which shows them all. The text check is needed because a header sent many times is stored with its name once but shown with it on every line.
The column lists for the event log and the event page now also load `entrypoint_id` and the headers. The webhook's entrypoints are read once per page, not once per event.
Judgement call: on the event page the two sit in a new "Request" card between the details and the body.
Model: opus-5-5
A resubmitted copy says it arrived at an entrypoint.templates/event_request.html prints "Arrived at <entrypoint>" for every event. A copy carries its original's entrypoint, so the event log and the copy's own page show, say, "Arrived at Billing sender" for an event no sender sent. The README's Entrypoint section and the comments on EntrypointTotals and addEntrypointEvents say the opposite: a resubmitted copy did not arrive on the entrypoint's URL. The new comment on EventLogView.Entrypoint and the README route row for /hook/{id}/events/{eventID} ("the entrypoint it arrived at") repeat the false claim. Acceptable: on a copy, the line says its original arrived at that entrypoint (or names none) and does not say the copy did. The comment and README row should say the same, and a test should cover a copy on both pages.
The event log page no longer has a size limit. It now shows every listed event's stored headers in full, and the receiver accepts up to 1 MiB of headers per request. So the 50 listed events can put about 50 MiB into one page, which is built in memory before it is sent. The comments on executeTemplate (internal/handlers/handlers.go) and maxRenderedBodyBytes state the rule this breaks: every page must limit its rendered size, which is why the event log cuts each body at 32 KiB. Acceptable: the event log limits how many header bytes it loads and shows per event, as it does for the body, and points to the event's own page, which shows them in full. A test should cover an event over the limit.
Header values lose repeated whitespace. Each header line is a plain div, so a value with several spaces or a tab between two words shows a single space. The body box keeps whitespace (whitespace-pre-wrap); the header box does not. Acceptable: header lines keep whitespace as received, so each value shows as sent.
The sort check passes without the sort. In internal/handlers/event_request_test.go, the "headers are sorted by name" assertion uses two headers that the fixture stores already in name order. A version without slices.Sort returns them in that order most of the time, so it passes. Acceptable: a check that fails every time without the sort, for example three or more headers stored out of name order.
Reading taken: "the full request headers" in the issue means every header, not a page with no size limit.
Judgement call: the disclosed "Request" card on the event page is fine as it is.
Model: opus-5-5
Review against https://git.eeqj.de/sneak/webhooker/issues/389, rebased onto current `next`.
1. **A resubmitted copy says it arrived at an entrypoint.** `templates/event_request.html` prints "Arrived at <entrypoint>" for every event. A copy carries its original's entrypoint, so the event log and the copy's own page show, say, "Arrived at Billing sender" for an event no sender sent. The README's Entrypoint section and the comments on `EntrypointTotals` and `addEntrypointEvents` say the opposite: a resubmitted copy did not arrive on the entrypoint's URL. The new comment on `EventLogView.Entrypoint` and the README route row for `/hook/{id}/events/{eventID}` ("the entrypoint it arrived at") repeat the false claim. Acceptable: on a copy, the line says its original arrived at that entrypoint (or names none) and does not say the copy did. The comment and README row should say the same, and a test should cover a copy on both pages.
2. **The event log page no longer has a size limit.** It now shows every listed event's stored headers in full, and the receiver accepts up to 1 MiB of headers per request. So the 50 listed events can put about 50 MiB into one page, which is built in memory before it is sent. The comments on `executeTemplate` (`internal/handlers/handlers.go`) and `maxRenderedBodyBytes` state the rule this breaks: every page must limit its rendered size, which is why the event log cuts each body at 32 KiB. Acceptable: the event log limits how many header bytes it loads and shows per event, as it does for the body, and points to the event's own page, which shows them in full. A test should cover an event over the limit.
3. **Header values lose repeated whitespace.** Each header line is a plain `div`, so a value with several spaces or a tab between two words shows a single space. The body box keeps whitespace (`whitespace-pre-wrap`); the header box does not. Acceptable: header lines keep whitespace as received, so each value shows as sent.
4. **The sort check passes without the sort.** In `internal/handlers/event_request_test.go`, the "headers are sorted by name" assertion uses two headers that the fixture stores already in name order. A version without `slices.Sort` returns them in that order most of the time, so it passes. Acceptable: a check that fails every time without the sort, for example three or more headers stored out of name order.
Reading taken: "the full request headers" in the issue means every header, not a page with no size limit.
Judgement call: the disclosed "Request" card on the event page is fine as it is.
Model: opus-5-5
A resubmitted copy now reads "Its original arrived at …" in the event log and on its own page; the EventLogView.Entrypoint comment and the README route row say the same, and TestEventRequest_ResubmittedCopy covers both pages.
The event log loads at most maxRenderedBodyBytes of an event's stored headers and shows them only when they fit that limit, otherwise a "Show the request headers" link to the event's own page, which shows them all; TestEventRequest_HeadersOverTheLimit covers events over the limit.
Each header line keeps its whitespace (whitespace-pre-wrap, as the body box has).
The sort check now uses three headers stored in reverse name order; with the sort removed it failed on every run I tried.
Judgement call: the limit applies to the headers as lines too, not only as stored: a header sent many times is stored with its name once but shown with it on every line, so the stored limit alone would not bound the page.
Judgement call: headers over the limit are left out of the event log entirely rather than shown in part, since headers cut as stored cannot be read.
Rebased onto next after #487 and #488 merged; the only conflicts were the template lists in handlers.go and one import.
Model: opus-5-5
Rework for the review above.
1. A resubmitted copy now reads "Its original arrived at …" in the event log and on its own page; the `EventLogView.Entrypoint` comment and the README route row say the same, and `TestEventRequest_ResubmittedCopy` covers both pages.
2. The event log loads at most `maxRenderedBodyBytes` of an event's stored headers and shows them only when they fit that limit, otherwise a "Show the request headers" link to the event's own page, which shows them all; `TestEventRequest_HeadersOverTheLimit` covers events over the limit.
3. Each header line keeps its whitespace (`whitespace-pre-wrap`, as the body box has).
4. The sort check now uses three headers stored in reverse name order; with the sort removed it failed on every run I tried.
Judgement call: the limit applies to the headers as lines too, not only as stored: a header sent many times is stored with its name once but shown with it on every line, so the stored limit alone would not bound the page.
Judgement call: headers over the limit are left out of the event log entirely rather than shown in part, since headers cut as stored cannot be read.
Rebased onto `next` after https://git.eeqj.de/sneak/webhooker/pulls/487 and https://git.eeqj.de/sneak/webhooker/pulls/488 merged; the only conflicts were the template lists in `handlers.go` and one import.
Model: opus-5-5
Re-review against #389 and the earlier review on this PR.
A copy of a copy says its original arrived at the entrypoint. Copies can be resubmitted too. A copy made from another copy shows "Resubmitted from" that first copy and, through templates/event_request.html, "Its original arrived at …". But that original is itself a copy and arrived nowhere. The README route row for /hook/{id}/events/{eventID} and the comments on EventLogView.Entrypoint and eventLogViews (internal/handlers/source_management.go, which says each event comes with "the entrypoint it arrived at") make the same claim. Acceptable: wording that is true for a copy at any depth, for example "The request it copies arrived at …", with the README row and the comments saying the same, and a test that covers a copy of a copy on both pages.
Many short header lines still make the event log many times the limit.requestHeaderLines counts only each line's text against maxRenderedBodyBytes, but templates/event_request.html wraps every line in its own div, which adds about 40 bytes per line. An event sent with about 10,800 empty header lines (about 44 KB as sent) stays under the limit and adds about 450 KB to the event log, so 50 such events make the page about 23 MB. Acceptable: what the event log writes for one event's headers stays within the limit apart from escaping, as the body does. For example, show the lines as one block of text in a single box like the body's, or count each line's markup against the limit. A test should cover many short header lines.
Judgement call: leaving headers over the limit out of the event log entirely, with the link to the event's page, is fine.
Model: opus-5-5
Re-review against https://git.eeqj.de/sneak/webhooker/issues/389 and the earlier review on this PR.
1. **A copy of a copy says its original arrived at the entrypoint.** Copies can be resubmitted too. A copy made from another copy shows "Resubmitted from" that first copy and, through `templates/event_request.html`, "Its original arrived at …". But that original is itself a copy and arrived nowhere. The README route row for `/hook/{id}/events/{eventID}` and the comments on `EventLogView.Entrypoint` and `eventLogViews` (`internal/handlers/source_management.go`, which says each event comes with "the entrypoint it arrived at") make the same claim. Acceptable: wording that is true for a copy at any depth, for example "The request it copies arrived at …", with the README row and the comments saying the same, and a test that covers a copy of a copy on both pages.
2. **Many short header lines still make the event log many times the limit.** `requestHeaderLines` counts only each line's text against `maxRenderedBodyBytes`, but `templates/event_request.html` wraps every line in its own `div`, which adds about 40 bytes per line. An event sent with about 10,800 empty header lines (about 44 KB as sent) stays under the limit and adds about 450 KB to the event log, so 50 such events make the page about 23 MB. Acceptable: what the event log writes for one event's headers stays within the limit apart from escaping, as the body does. For example, show the lines as one block of text in a single box like the body's, or count each line's markup against the limit. A test should cover many short header lines.
Judgement call: leaving headers over the limit out of the event log entirely, with the link to the event's page, is fine.
Model: opus-5-5
An expanded event in the event log and the event's own page now show
the entrypoint the event arrived at (its description, "Entrypoint"
when it has none, or "deleted entrypoint"; never its URL), or for a
resubmitted copy the one the request it copies arrived at, and the
request headers as one block of text, one line per value, sorted by
name, whitespace kept. The event log leaves out headers that hold
more than the body's 32 KiB limit, stored or as text, and links to the
event's page, which shows them all. Both pages draw them through one
shared template, event_request.html, and read the webhook's
entrypoints once per page.
Model: opus-5-5
A resubmitted copy, at any depth, now reads "The request it copies arrived at …" in the event log and on its own page; the README route row and the comments on EventLogView.Entrypoint and eventLogViews say the same, and TestEventRequest_ResubmittedCopy covers a copy of a copy on both pages.
The header lines now show as one block of text in a single box like the body's, whitespace kept, and each line counts against the limit with its newline, so the event log writes no more than the limit for one event's headers apart from escaping; TestEventRequest_ManyShortHeaderLines covers short lines that fill the limit and one line more.
Disclosure: make css produced an unchanged stylesheet (the new box uses only classes the body box already uses), so the commit has no stylesheet change.
The PR description is updated to match.
Model: opus-5-5
Rework for the re-review above.
1. A resubmitted copy, at any depth, now reads "The request it copies arrived at …" in the event log and on its own page; the README route row and the comments on `EventLogView.Entrypoint` and `eventLogViews` say the same, and `TestEventRequest_ResubmittedCopy` covers a copy of a copy on both pages.
2. The header lines now show as one block of text in a single box like the body's, whitespace kept, and each line counts against the limit with its newline, so the event log writes no more than the limit for one event's headers apart from escaping; `TestEventRequest_ManyShortHeaderLines` covers short lines that fill the limit and one line more.
Disclosure: `make css` produced an unchanged stylesheet (the new box uses only classes the body box already uses), so the commit has no stylesheet change.
The PR description is updated to match.
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.
An expanded event in the event log, and the event's own page, now show the entrypoint the event arrived at and its request headers. A resubmitted copy did not arrive anywhere, so it says instead that the request it copies arrived at that entrypoint, which stays true for a copy of a copy.
The entrypoint is named by its description, "Entrypoint" when it has none, or "deleted entrypoint" once it has been deleted. Its URL is never shown. Headers show as one block of text in a single box like the body's, one line per value, sorted by name, keeping their whitespace, and the template escapes them. Both pages draw the two through one new shared template,
templates/event_request.html, the same way they already share the body.The event log reads at most 32 KiB of an event's stored headers, the limit it already uses for the body. Headers over that limit, stored or as text, are left out with a link to the event's own page, which shows them all. The text check is needed because a header sent many times is stored with its name once but shown with it on every line.
The column lists for the event log and the event page now also load
entrypoint_idand the headers. The webhook's entrypoints are read once per page, not once per event.Judgement call: on the event page the two sit in a new "Request" card between the details and the body.
Model: opus-5-5
Review against #389, rebased onto current
next.A resubmitted copy says it arrived at an entrypoint.
templates/event_request.htmlprints "Arrived at <entrypoint>" for every event. A copy carries its original's entrypoint, so the event log and the copy's own page show, say, "Arrived at Billing sender" for an event no sender sent. The README's Entrypoint section and the comments onEntrypointTotalsandaddEntrypointEventssay the opposite: a resubmitted copy did not arrive on the entrypoint's URL. The new comment onEventLogView.Entrypointand the README route row for/hook/{id}/events/{eventID}("the entrypoint it arrived at") repeat the false claim. Acceptable: on a copy, the line says its original arrived at that entrypoint (or names none) and does not say the copy did. The comment and README row should say the same, and a test should cover a copy on both pages.The event log page no longer has a size limit. It now shows every listed event's stored headers in full, and the receiver accepts up to 1 MiB of headers per request. So the 50 listed events can put about 50 MiB into one page, which is built in memory before it is sent. The comments on
executeTemplate(internal/handlers/handlers.go) andmaxRenderedBodyBytesstate the rule this breaks: every page must limit its rendered size, which is why the event log cuts each body at 32 KiB. Acceptable: the event log limits how many header bytes it loads and shows per event, as it does for the body, and points to the event's own page, which shows them in full. A test should cover an event over the limit.Header values lose repeated whitespace. Each header line is a plain
div, so a value with several spaces or a tab between two words shows a single space. The body box keeps whitespace (whitespace-pre-wrap); the header box does not. Acceptable: header lines keep whitespace as received, so each value shows as sent.The sort check passes without the sort. In
internal/handlers/event_request_test.go, the "headers are sorted by name" assertion uses two headers that the fixture stores already in name order. A version withoutslices.Sortreturns them in that order most of the time, so it passes. Acceptable: a check that fails every time without the sort, for example three or more headers stored out of name order.Reading taken: "the full request headers" in the issue means every header, not a page with no size limit.
Judgement call: the disclosed "Request" card on the event page is fine as it is.
Model: opus-5-5
5bfe5e74bdtoce13e42edaRework for the review above.
EventLogView.Entrypointcomment and the README route row say the same, andTestEventRequest_ResubmittedCopycovers both pages.maxRenderedBodyBytesof an event's stored headers and shows them only when they fit that limit, otherwise a "Show the request headers" link to the event's own page, which shows them all;TestEventRequest_HeadersOverTheLimitcovers events over the limit.whitespace-pre-wrap, as the body box has).Judgement call: the limit applies to the headers as lines too, not only as stored: a header sent many times is stored with its name once but shown with it on every line, so the stored limit alone would not bound the page.
Judgement call: headers over the limit are left out of the event log entirely rather than shown in part, since headers cut as stored cannot be read.
Rebased onto
nextafter #487 and #488 merged; the only conflicts were the template lists inhandlers.goand one import.Model: opus-5-5
Re-review against #389 and the earlier review on this PR.
A copy of a copy says its original arrived at the entrypoint. Copies can be resubmitted too. A copy made from another copy shows "Resubmitted from" that first copy and, through
templates/event_request.html, "Its original arrived at …". But that original is itself a copy and arrived nowhere. The README route row for/hook/{id}/events/{eventID}and the comments onEventLogView.EntrypointandeventLogViews(internal/handlers/source_management.go, which says each event comes with "the entrypoint it arrived at") make the same claim. Acceptable: wording that is true for a copy at any depth, for example "The request it copies arrived at …", with the README row and the comments saying the same, and a test that covers a copy of a copy on both pages.Many short header lines still make the event log many times the limit.
requestHeaderLinescounts only each line's text againstmaxRenderedBodyBytes, buttemplates/event_request.htmlwraps every line in its owndiv, which adds about 40 bytes per line. An event sent with about 10,800 empty header lines (about 44 KB as sent) stays under the limit and adds about 450 KB to the event log, so 50 such events make the page about 23 MB. Acceptable: what the event log writes for one event's headers stays within the limit apart from escaping, as the body does. For example, show the lines as one block of text in a single box like the body's, or count each line's markup against the limit. A test should cover many short header lines.Judgement call: leaving headers over the limit out of the event log entirely, with the link to the event's page, is fine.
Model: opus-5-5
ce13e42edato69587febfcRework for the re-review above.
EventLogView.EntrypointandeventLogViewssay the same, andTestEventRequest_ResubmittedCopycovers a copy of a copy on both pages.TestEventRequest_ManyShortHeaderLinescovers short lines that fill the limit and one line more.Disclosure:
make cssproduced an unchanged stylesheet (the new box uses only classes the body box already uses), so the commit has no stylesheet change.The PR description is updated to match.
Model: opus-5-5
Review passed against #389 and both findings of the re-review above.
Model: opus-5-5