audit the whole app for stupid cases of missing functionality or basic things like this (like the stats panel at the top that i requested).
What is missing: the event log lists every event, 25 to a page (HandleSourceLogs in internal/handlers/source_management.go). There is no way to list only the events that have a failed delivery. Today that means paging and expanding by hand. Once #349 cuts the log to the 50 most recent events, a failure older than those cannot be found from the UI at all.
Definition of done:
The event log has a control to show only events with at least one failed delivery, and one to show only events with a delivery still pending or retrying. Each control shows how many events match.
The filtered list applies the same row limit as the unfiltered one.
The filter queries delivery status through the existing status index (idx_deliveries_status). It never reads event bodies to decide.
Tests: each filter returns exactly the matching events, and its count matches the list.
PRIORITY: from the owner's audit request of 1 October (#377), in the tier of #367 to #376.
Model: opus-5-5
Owner's request, https://git.eeqj.de/sneak/webhooker/issues/377 (chat, 2026-10-01):
> audit the whole app for stupid cases of missing functionality or basic things like this (like the stats panel at the top that i requested).
What is missing: the event log lists every event, 25 to a page (`HandleSourceLogs` in `internal/handlers/source_management.go`). There is no way to list only the events that have a failed delivery. Today that means paging and expanding by hand. Once https://git.eeqj.de/sneak/webhooker/issues/349 cuts the log to the 50 most recent events, a failure older than those cannot be found from the UI at all.
Definition of done:
- The event log has a control to show only events with at least one failed delivery, and one to show only events with a delivery still pending or retrying. Each control shows how many events match.
- The filtered list applies the same row limit as the unfiltered one.
- The filter queries delivery status through the existing status index (`idx_deliveries_status`). It never reads event bodies to decide.
- Tests: each filter returns exactly the matching events, and its count matches the list.
PRIORITY: from the owner's audit request of 1 October (https://git.eeqj.de/sneak/webhooker/issues/377), in the tier of https://git.eeqj.de/sneak/webhooker/issues/367 to https://git.eeqj.de/sneak/webhooker/issues/376.
Model: opus-5-5
clawbot
self-assigned this 2026-10-01 22:06:20 +02:00
The event log gets three plain links above the list: All, Failed (N) and Pending (N). They are links with a show query parameter (failed, pending), so they work without the page's script library, and the current one is marked.
Failed lists events with at least one delivery whose status is failed; Pending, events with a delivery still pending or retrying. Both use the same 50-row limit and newest-first order as the full list since #349.
The lists and their counts select event IDs from deliveries by status through idx_deliveries_status; no event body is read to decide. Each count is the number of distinct matching events, which can exceed the 50 shown.
An unknown show value shows the full list. The comments and README line that name the query parameters the service reads gain show.
Tests: each filter returns exactly the matching events, its count matches, and an event with both a failed and a delivered delivery is listed under Failed once.
Model: opus-5-5
Plan.
- The event log gets three plain links above the list: All, Failed (N) and Pending (N). They are links with a `show` query parameter (`failed`, `pending`), so they work without the page's script library, and the current one is marked.
- Failed lists events with at least one delivery whose status is failed; Pending, events with a delivery still pending or retrying. Both use the same 50-row limit and newest-first order as the full list since https://git.eeqj.de/sneak/webhooker/issues/349.
- The lists and their counts select event IDs from deliveries by status through `idx_deliveries_status`; no event body is read to decide. Each count is the number of distinct matching events, which can exceed the 50 shown.
- An unknown `show` value shows the full list. The comments and README line that name the query parameters the service reads gain `show`.
- Tests: each filter returns exactly the matching events, its count matches, and an event with both a failed and a delivered delivery is listed under Failed once.
Model: opus-5-5
Built in #490, following the plan above: the event log has All, Failed (N) and Pending (N) links above the list, carried in a show query parameter. Failed and Pending keep the full log's 50-row limit and order, and each count is of distinct matching events, so it can exceed the rows shown.
EXPLAIN QUERY PLAN: the filtered list and both counts search deliveries through idx_deliveries_status (status=? AND deleted_at=?), and a database test now holds that.
Judgement call: the counts read only the matching deliveries (distinct event IDs), not the events table, which would walk every event row; they equal the filtered list's total because retention deletes an event's deliveries with it.
Judgement call: Replay and Resubmit return to the full log, not the filtered one.
Judgement call: under a filter, the event total beside the heading counts the filtered events.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/webhooker/pulls/490, following the plan above: the event log has All, Failed (N) and Pending (N) links above the list, carried in a `show` query parameter. Failed and Pending keep the full log's 50-row limit and order, and each count is of distinct matching events, so it can exceed the rows shown.
EXPLAIN QUERY PLAN: the filtered list and both counts search `deliveries` through `idx_deliveries_status (status=? AND deleted_at=?)`, and a database test now holds that.
- Judgement call: the counts read only the matching deliveries (distinct event IDs), not the events table, which would walk every event row; they equal the filtered list's total because retention deletes an event's deliveries with it.
- Judgement call: Replay and Resubmit return to the full log, not the filtered one.
- Judgement call: under a filter, the event total beside the heading counts the filtered events.
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 request, #377 (chat, 2026-10-01):
What is missing: the event log lists every event, 25 to a page (
HandleSourceLogsininternal/handlers/source_management.go). There is no way to list only the events that have a failed delivery. Today that means paging and expanding by hand. Once #349 cuts the log to the 50 most recent events, a failure older than those cannot be found from the UI at all.Definition of done:
idx_deliveries_status). It never reads event bodies to decide.PRIORITY: from the owner's audit request of 1 October (#377), in the tier of #367 to #376.
Model: opus-5-5
Plan.
showquery parameter (failed,pending), so they work without the page's script library, and the current one is marked.idx_deliveries_status; no event body is read to decide. Each count is the number of distinct matching events, which can exceed the 50 shown.showvalue shows the full list. The comments and README line that name the query parameters the service reads gainshow.Model: opus-5-5
Built in #490, following the plan above: the event log has All, Failed (N) and Pending (N) links above the list, carried in a
showquery parameter. Failed and Pending keep the full log's 50-row limit and order, and each count is of distinct matching events, so it can exceed the rows shown.EXPLAIN QUERY PLAN: the filtered list and both counts search
deliveriesthroughidx_deliveries_status (status=? AND deleted_at=?), and a database test now holds that.Model: opus-5-5