the "recent events" at the bottom should link to a per-event view, and they should be expandable to show the event body.
And a few minutes later (chat, ~18:56 UTC):
in both the "recent events" expansion, as well as the "recent events" page, as well as the to-be-created per-event viewer, don't truncate bodies that are under 32k. if they're valid json, format them. if they're more than 200 lines, put them in their own little scroll well so they don't make the page huge.
PRIORITY: an owner's direct request of 1 October, in the same tier as #367 and #368: after the production path, ahead of the older backlog.
Related: #347 (the recent-events columns, PR 361), #348 and #349 (event log expand/collapse, only the newest expanded on load). Build on them and do not conflict with PR 361.
Definition of done:
Each row in the recent-events list at the bottom of the per-webhook page links to a page for that one event. That page shows the event's metadata, its full body, and every delivery of it with status.
Each row expands in place to show the event body and collapses again. Following 349, only the newest row is expanded on load.
Body display is the same in all three places: the recent-events expansion on the webhook page, the recent events / event log page, and the per-event page.
Bodies under 32 KiB are shown in full, never truncated.
A body that is valid JSON is shown pretty-printed.
A body of more than 200 lines (after formatting) sits in its own fixed-height scrolling box, so the page does not grow huge.
Bodies of 32 KiB or more: the comment on this issue states the handling before implementation (recommendation: the list and expansion show the first 32 KiB with a link to the per-event page, which shows it in full in the scroll box).
Bodies are always HTML-escaped. Binary content is never dumped raw.
One shared rendering path serves all three places, so the rules cannot drift apart.
The per-event page is behind the same admin login as the rest of the UI. Its URL does not expose the inbound webhook UUID.
Tests cover the link, the expand toggle, the per-event page, the 32 KiB boundary, JSON formatting (valid and invalid JSON) and the 200-line scroll box. Lands on next with an independent review.
model: opus-5-5
Owner's words (chat, 2026-10-01 ~18:5x UTC):
> the "recent events" at the bottom should link to a per-event view, and they should be expandable to show the event body.
And a few minutes later (chat, ~18:56 UTC):
> in both the "recent events" expansion, as well as the "recent events" page, as well as the to-be-created per-event viewer, don't truncate bodies that are under 32k. if they're valid json, format them. if they're more than 200 lines, put them in their own little scroll well so they don't make the page huge.
PRIORITY: an owner's direct request of 1 October, in the same tier as https://git.eeqj.de/sneak/webhooker/issues/367 and https://git.eeqj.de/sneak/webhooker/issues/368: after the production path, ahead of the older backlog.
Related: https://git.eeqj.de/sneak/webhooker/issues/347 (the recent-events columns, PR 361), https://git.eeqj.de/sneak/webhooker/issues/348 and https://git.eeqj.de/sneak/webhooker/issues/349 (event log expand/collapse, only the newest expanded on load). Build on them and do not conflict with PR 361.
Definition of done:
- Each row in the recent-events list at the bottom of the per-webhook page links to a page for that one event. That page shows the event's metadata, its full body, and every delivery of it with status.
- Each row expands in place to show the event body and collapses again. Following 349, only the newest row is expanded on load.
- Body display is the same in all three places: the recent-events expansion on the webhook page, the recent events / event log page, and the per-event page.
- Bodies under 32 KiB are shown in full, never truncated.
- A body that is valid JSON is shown pretty-printed.
- A body of more than 200 lines (after formatting) sits in its own fixed-height scrolling box, so the page does not grow huge.
- Bodies of 32 KiB or more: the comment on this issue states the handling before implementation (recommendation: the list and expansion show the first 32 KiB with a link to the per-event page, which shows it in full in the scroll box).
- Bodies are always HTML-escaped. Binary content is never dumped raw.
- One shared rendering path serves all three places, so the rules cannot drift apart.
- The per-event page is behind the same admin login as the rest of the UI. Its URL does not expose the inbound webhook UUID.
- Tests cover the link, the expand toggle, the per-event page, the 32 KiB boundary, JSON formatting (valid and invalid JSON) and the 200-line scroll box. Lands on `next` with an independent review.
model: opus-5-5
clawbot
self-assigned this 2026-10-01 20:55:44 +02:00
clawbot
changed title from Recent events on the webhook page: each links to a per-event page and expands to show the body to Event bodies: per-event page, expandable recent events, full bodies under 32k, JSON formatted, scroll well over 200 lines2026-10-01 20:56:39 +02:00
Per-event page:/hook/ID/events/EVENTID (the path scheme of #367), behind the admin login like the other webhook pages. Its URL names the webhook and the event, never the entrypoint UUID. It shows the event's metadata, its body, and every delivery of it with its status.
One shared renderer: one Go function turns a stored body into what the pages show, and one template displays it; the recent-events expansion, the event log and the per-event page all use both. The function decides:
a body that is not valid UTF-8 is binary and is never shown inline; the page shows its size and content type with the existing download link;
a body that is valid JSON is pretty-printed;
a body of more than 200 lines, counted after formatting, goes in a fixed-height scrolling box;
the template escapes everything.
Bodies of 32 KiB or more: the expansion and the event log show the first 32 KiB unformatted (a cut JSON document is no longer valid JSON), with a note and a link to the per-event page. The per-event page shows the whole body, formatted when it is valid JSON, in the scroll box. The receiver already caps a body at 1 MB, so that is the most the page renders. The download link stays.
Recent events: each row links to its per-event page and expands in place; only the newest row is expanded on load.
Sequencing: starts once #361 (the recent-events list), 367 (the paths) and #371 (Alpine does not run under the page's security policy, which this issue's expand and collapse need) are on next.
Model: opus-5-5
Plan.
- **Per-event page:** `/hook/ID/events/EVENTID` (the path scheme of https://git.eeqj.de/sneak/webhooker/issues/367), behind the admin login like the other webhook pages. Its URL names the webhook and the event, never the entrypoint UUID. It shows the event's metadata, its body, and every delivery of it with its status.
- **One shared renderer:** one Go function turns a stored body into what the pages show, and one template displays it; the recent-events expansion, the event log and the per-event page all use both. The function decides:
- a body that is not valid UTF-8 is binary and is never shown inline; the page shows its size and content type with the existing download link;
- a body that is valid JSON is pretty-printed;
- a body of more than 200 lines, counted after formatting, goes in a fixed-height scrolling box;
- the template escapes everything.
- **Bodies of 32 KiB or more:** the expansion and the event log show the first 32 KiB unformatted (a cut JSON document is no longer valid JSON), with a note and a link to the per-event page. The per-event page shows the whole body, formatted when it is valid JSON, in the scroll box. The receiver already caps a body at 1 MB, so that is the most the page renders. The download link stays.
- **Recent events:** each row links to its per-event page and expands in place; only the newest row is expanded on load.
- **Sequencing:** starts once https://git.eeqj.de/sneak/webhooker/pulls/361 (the recent-events list), 367 (the paths) and https://git.eeqj.de/sneak/webhooker/issues/371 (Alpine does not run under the page's security policy, which this issue's expand and collapse need) are on `next`.
Model: opus-5-5
Found again by the audit for #377, on current next: a 2 KiB binary body is dumped raw into the event log as a block of replacement characters, and a 300 KiB JSON body shows its first 8 KiB, unformatted. One addition for the per-event page: a resubmitted copy names its original only as a bare ID ("Resubmitted from event 9ce0782a-…"), so that ID should link to the original's per-event page.
Model: opus-5-5
Found again by the audit for https://git.eeqj.de/sneak/webhooker/issues/377, on current `next`: a 2 KiB binary body is dumped raw into the event log as a block of replacement characters, and a 300 KiB JSON body shows its first 8 KiB, unformatted. One addition for the per-event page: a resubmitted copy names its original only as a bare ID ("Resubmitted from event 9ce0782a-…"), so that ID should link to the original's per-event page.
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.
Owner's words (chat, 2026-10-01 ~18:5x UTC):
And a few minutes later (chat, ~18:56 UTC):
PRIORITY: an owner's direct request of 1 October, in the same tier as #367 and #368: after the production path, ahead of the older backlog.
Related: #347 (the recent-events columns, PR 361), #348 and #349 (event log expand/collapse, only the newest expanded on load). Build on them and do not conflict with PR 361.
Definition of done:
nextwith an independent review.model: opus-5-5
Recent events on the webhook page: each links to a per-event page and expands to show the bodyto Event bodies: per-event page, expandable recent events, full bodies under 32k, JSON formatted, scroll well over 200 linesPlan.
/hook/ID/events/EVENTID(the path scheme of #367), behind the admin login like the other webhook pages. Its URL names the webhook and the event, never the entrypoint UUID. It shows the event's metadata, its body, and every delivery of it with its status.next.Model: opus-5-5
Found again by the audit for #377, on current
next: a 2 KiB binary body is dumped raw into the event log as a block of replacement characters, and a 300 KiB JSON body shows its first 8 KiB, unformatted. One addition for the per-event page: a resubmitted copy names its original only as a bare ID ("Resubmitted from event 9ce0782a-…"), so that ID should link to the original's per-event page.Model: opus-5-5