first off, the "recent events" at the bottom of a hook's page needs to show 50 events, and it needs to show the relative time, with the full UTC timestamp shown on hover. it also needs a couple more columns, like size and time spent processing it and anything else pertinent. if there is only one http receiver, it should show the status code of that delivery (color coded).
Definition of done, on the recent-events list at the bottom of a webhook's page:
It shows the 50 most recent events, newest first, limited in the database query.
Each event's time is shown relative ("3 minutes ago"), with the full UTC timestamp (e.g. 2026-09-29 09:31:04 UTC) on hover.
New columns: the event's size (body size, human-readable), the time webhooker spent processing it, and any other already-recorded detail that is pertinent to reading the list (the PR says which were added and why). Say on the PR exactly what "time spent processing" measures; if webhooker does not record what is needed, record it.
When the webhook has exactly one HTTP target (use the repo's own term for it), each row shows the HTTP status code of that target's delivery for the event, colour-coded: 2xx green, 3xx neutral, 4xx amber, 5xx red; no response yet, or a failed connection, shown distinctly and labelled.
The page stays readable at phone width.
Tests cover the 50-row limit and the single-target status column (shown with one HTTP target, absent with none or several).
Model: opus-5-5
sneak, 2026-09-29 in chat (verbatim):
> first off, the "recent events" at the bottom of a hook's page needs to show 50 events, and it needs to show the relative time, with the full UTC timestamp shown on hover. it also needs a couple more columns, like size and time spent processing it and anything else pertinent. if there is only one http receiver, it should show the status code of that delivery (color coded).
Definition of done, on the recent-events list at the bottom of a webhook's page:
- It shows the 50 most recent events, newest first, limited in the database query.
- Each event's time is shown relative ("3 minutes ago"), with the full UTC timestamp (e.g. `2026-09-29 09:31:04 UTC`) on hover.
- New columns: the event's size (body size, human-readable), the time webhooker spent processing it, and any other already-recorded detail that is pertinent to reading the list (the PR says which were added and why). Say on the PR exactly what "time spent processing" measures; if webhooker does not record what is needed, record it.
- When the webhook has exactly one HTTP target (use the repo's own term for it), each row shows the HTTP status code of that target's delivery for the event, colour-coded: 2xx green, 3xx neutral, 4xx amber, 5xx red; no response yet, or a failed connection, shown distinctly and labelled.
- The page stays readable at phone width.
- Tests cover the 50-row limit and the single-target status column (shown with one HTTP target, absent with none or several).
Model: opus-5-5
clawbot
self-assigned this 2026-09-29 11:33:06 +02:00
Plan. The list is rendered by renderSourceDetail in internal/handlers/source_management.go (the recent-events query around line 425) and templates/source_detail.html.
Limit: 50 rows, limited in the query.
Times: relative time rendered on the server. A small template helper is enough; the page needs no client script for it. The UTC timestamp goes in the title attribute.
Processing time: say exactly what it measures, from receipt to the last delivery's outcome or whatever the recorded columns support. If nothing records it, add the smallest column that does. Before 1.0 that means changing the existing schema definition, per REPO_POLICIES.md.
Single HTTP target status: load it in one batched query for the page's 50 events, not one query per row.
Colours: use the classes the page already uses for status elsewhere where they fit.
Styling:static/css/tailwind.css is the compiled Tailwind stylesheet and is committed. A class the page uses must already be in that file. If it is not, prefer a small plain rule in static/css/style.css. Regenerate tailwind.css only through make css, and disclose it on the PR if you do (the unpinned tool is #231).
Browser checks: headless Chrome in a container, with a small data set built in batches (the standing RAM cap), the container named with webhooker and your role, removed afterwards. Publish no screenshots or logs on the tracker.
templates/source_detail.html is also touched by #350, at the page's outer container. Whichever lands second rebases.
Model: opus-5-5
Plan. The list is rendered by `renderSourceDetail` in `internal/handlers/source_management.go` (the recent-events query around line 425) and `templates/source_detail.html`.
- **Limit:** 50 rows, limited in the query.
- **Times:** relative time rendered on the server. A small template helper is enough; the page needs no client script for it. The UTC timestamp goes in the `title` attribute.
- **Processing time:** say exactly what it measures, from receipt to the last delivery's outcome or whatever the recorded columns support. If nothing records it, add the smallest column that does. Before 1.0 that means changing the existing schema definition, per `REPO_POLICIES.md`.
- **Single HTTP target status:** load it in one batched query for the page's 50 events, not one query per row.
- **Colours:** use the classes the page already uses for status elsewhere where they fit.
- **Styling:** `static/css/tailwind.css` is the compiled Tailwind stylesheet and is committed. A class the page uses must already be in that file. If it is not, prefer a small plain rule in `static/css/style.css`. Regenerate `tailwind.css` only through `make css`, and disclose it on the PR if you do (the unpinned tool is https://git.eeqj.de/sneak/webhooker/issues/231).
- **Browser checks:** headless Chrome in a container, with a small data set built in batches (the standing RAM cap), the container named with `webhooker` and your role, removed afterwards. Publish no screenshots or logs on the tracker.
- `templates/source_detail.html` is also touched by https://git.eeqj.de/sneak/webhooker/issues/350, at the page's outer container. Whichever lands second rebases.
Model: opus-5-5
Built in #361: the list shows the 50 newest events with the time received (relative, UTC on hover), body size, processing time, a resubmitted-copy marker and, when the webhook has exactly one HTTP target, that target's colour-coded HTTP status. The PR says exactly what processing time measures and lists the judgement calls.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/webhooker/pulls/361: the list shows the 50 newest events with the time received (relative, UTC on hover), body size, processing time, a resubmitted-copy marker and, when the webhook has exactly one HTTP target, that target's colour-coded HTTP status. The PR says exactly what processing time measures and lists the judgement calls.
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.
sneak, 2026-09-29 in chat (verbatim):
Definition of done, on the recent-events list at the bottom of a webhook's page:
2026-09-29 09:31:04 UTC) on hover.Model: opus-5-5
Plan. The list is rendered by
renderSourceDetailininternal/handlers/source_management.go(the recent-events query around line 425) andtemplates/source_detail.html.titleattribute.REPO_POLICIES.md.static/css/tailwind.cssis the compiled Tailwind stylesheet and is committed. A class the page uses must already be in that file. If it is not, prefer a small plain rule instatic/css/style.css. Regeneratetailwind.cssonly throughmake css, and disclose it on the PR if you do (the unpinned tool is #231).webhookerand your role, removed afterwards. Publish no screenshots or logs on the tracker.templates/source_detail.htmlis also touched by #350, at the page's outer container. Whichever lands second rebases.Model: opus-5-5
Built in #361: the list shows the 50 newest events with the time received (relative, UTC on hover), body size, processing time, a resubmitted-copy marker and, when the webhook has exactly one HTTP target, that target's colour-coded HTTP status. The PR says exactly what processing time measures and lists the judgement calls.
Model: opus-5-5