Event log: show only the events with a failed or a pending delivery (closes #390)
check / check (push) Successful in 3m14s

The event log gains three links above the list: All, Failed (N) and Pending (N), carried in a `show` query parameter (`failed`, `pending`); any other value shows every event. Failed lists the events with at least one failed delivery, Pending those with one pending or retrying, under the same 50-row limit and newest-first order as the full list. Events are picked by their deliveries' status through `idx_deliveries_status`; each count is the number of distinct matching events, read from the deliveries alone, and can exceed the 50 shown. An empty filtered list says that no event matches. The README and the comments that name the query parameters the service reads now include `show`.

Model: opus-5-5
This commit is contained in:
2026-10-03 02:08:35 +00:00
parent ea8384f4a2
commit ae2ce55575
11 changed files with 363 additions and 39 deletions
+5 -4
View File
@@ -1971,7 +1971,7 @@ tags, so `AutoMigrate` creates them on a fresh database:
| Table | Columns | Serves |
| ------------------ | --------------------------- | ------ |
| `deliveries` | `status`, `deleted_at`, `finished_at`, `target_id` | Startup recovery, the retry and pending sweeps every 60 seconds and the queue-depth sampler every 30 seconds, which select deliveries by status, and the webhook page's statistics and target list and the webhook list, which count each target's deliveries by status and when they finished |
| `deliveries` | `status`, `deleted_at`, `finished_at`, `target_id` | Startup recovery, the retry and pending sweeps every 60 seconds and the queue-depth sampler every 30 seconds, which select deliveries by status, the webhook page's statistics and target list and the webhook list, which count each target's deliveries by status and when they finished, and the event log, which lists and counts the events with a failed delivery or one pending or retrying |
| `deliveries` | `event_id`, `deleted_at` | The event log, which loads each event's deliveries, and retention, which counts and deletes the deliveries of expired events |
| `delivery_results` | `delivery_id`, `deleted_at` | The event log, which loads the attempts of a page's deliveries, and retention, which deletes the attempts of expired events |
| `events` | `deleted_at`, `created_at` | The webhook page's statistics, which count recent events |
@@ -2538,8 +2538,9 @@ The query string is never logged; it is replaced by the fixed marker
limiter in front of them, so a query on a fixed 200 URL would otherwise
buy the same amplification as an invented path. Nothing debuggable is
lost: the only query parameters this service reads are the login page's
`next`, the page to return to, and `notice`, which names the line a page
shows after an action.
`next`, the page to return to, `notice`, which names the line a page
shows after an action, and the event log's `show`, which picks the events
it lists.
Client-supplied request content does not leave the host by the other
route either. The Sentry SDK attaches the request to every event it
@@ -3052,7 +3053,7 @@ returns to the page that was asked for.
| `GET` | `/hook/{id}/edit` | Edit webhook form |
| `POST` | `/hook/{id}/edit` | Edit webhook submission |
| `POST` | `/hook/{id}/delete` | Delete webhook |
| `GET` | `/hook/{id}/events` | Full Event Log |
| `GET` | `/hook/{id}/events` | Full Event Log. `?show=failed` lists only the events with a failed delivery, and `?show=pending` only those with a delivery pending or retrying |
| `GET` | `/hook/{id}/events/{eventID}` | One event's own page: its details, its whole body and every delivery of it |
| `GET` | `/hook/{id}/events/{eventID}/body` | Download an event's stored body. The pages show a body as text, cut at 32 KiB in the recent events and the event log, and leave a binary one out, so this is the only route that serves the stored bytes; it is offered wherever a body is cut or binary |
| `POST` | `/hook/{id}/deliveries/{deliveryID}/replay` | Replay a finished delivery: creates a new delivery for the same event against the target's current configuration (30 per minute per bucket, then `429`) |