Event log: show only the events with a failed or a pending delivery (closes #390)

The event log had no way to list only the events whose delivery failed, and once it showed only the 50 newest, an older failure could not be found at all. It now has All, Failed (N) and Pending (N) links, carried in a `show` query parameter, so they work without the page's script library. Each filtered list keeps the 50-row limit and newest-first order, and lists an event once. It finds matching deliveries through `idx_deliveries_status` and looks their events up by ID, so its cost follows the matches, not the webhook's size. Replay returns to the list it was pressed in. The heading line says what a filter counts. Model: opus-5-5
2026-10-03 05:40:34 +02:00
parent 9079a3219d
commit 7e779f7fce
13 changed files with 484 additions and 44 deletions
@@ -1989,7 +1989,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 |
@@ -2592,8 +2592,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 sign-in 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
@@ -3106,7 +3107,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, the entrypoint it arrived at (for a resubmitted copy, the one the request it copies arrived at), its request headers, 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`) |