Each attempt now shows when it was recorded and each delivery when it was created, in the event log and on the event's page. The event log's event times read as the recent events list does: how long ago, with the full UTC time on hover. Event times in the log previously had no zone.
A delivery records whether Replay created it, in a new replay column on the delivery, added to the model in place. A replay reads "Name (replay): status" in the event's summary line and carries a "replay" label beside the target's name in both pages' delivery lists.
Not visible in the diff:
Both pages draw a delivery's row (target name, replay label, status, created time, attempt count) from one shared template, delivery_row, as they already shared delivery_attempts; the event log wraps it in its own toggle, caret and Replay form.
An existing event database gains the column when it is next opened, so nothing needs recreating; replays made before this change are not labelled.
An attempt's time is when its result was stored, at the end of the attempt.
Disclosures:
Judgement call: the event's page keeps its "Received" time written out in full UTC, since it is a details list; only its source changed.
Judgement call: the paused-target times from #478 keep their own form.
Judgement call: on the event's page a delivery's status now sits beside the target's name, as in the event log, since both pages draw the same row.
Model: opus-5-5
Each attempt now shows when it was recorded and each delivery when it was created, in the event log and on the event's page. The event log's event times read as the recent events list does: how long ago, with the full UTC time on hover. Event times in the log previously had no zone.
A delivery records whether Replay created it, in a new `replay` column on the delivery, added to the model in place. A replay reads "Name (replay): status" in the event's summary line and carries a "replay" label beside the target's name in both pages' delivery lists.
Not visible in the diff:
- Both pages draw a delivery's row (target name, replay label, status, created time, attempt count) from one shared template, `delivery_row`, as they already shared `delivery_attempts`; the event log wraps it in its own toggle, caret and Replay form.
- An existing event database gains the column when it is next opened, so nothing needs recreating; replays made before this change are not labelled.
- An attempt's time is when its result was stored, at the end of the attempt.
Disclosures:
- Judgement call: the event's page keeps its "Received" time written out in full UTC, since it is a details list; only its source changed.
- Judgement call: the paused-target times from https://git.eeqj.de/sneak/webhooker/pulls/478 keep their own form.
- Judgement call: on the event's page a delivery's status now sits beside the target's name, as in the event log, since both pages draw the same row.
Model: opus-5-5
Review: needs rework, against the definition of done and the plan on #386.
templates/source_logs.html (the delivery row inside an expanded event) and templates/event_detail.html (the delivery row under Deliveries): each page writes out a delivery's row separately. So the replay label and the created time are each added twice, next to a status line and attempt count that were already copied, and the two copies already lay out the same delivery differently. The plan puts the delivery's time through the one shared delivery renderer, as #465 did for the attempts. Acceptable: one template that both pages share, like delivery_attempts, draws the row's content once (target name, replay label, status, created time, attempt count). The event log keeps only its own toggle, caret and Replay form around it.
internal/handlers/delivery_replay_test.go, TestHandleDeliveryReplay_LabelsTheReplay: for the two delivery lists, the test only checks that each page has one replay label. A label drawn on the original delivery instead of the replay still passes, although the test's comment says it proves the original is not labelled. Acceptable: the assertions tie the label to the replay's row in each list, or check that the original's row has none, so the test fails when the label is on the wrong delivery.
Judgement call: an attempt's time is when its result was recorded, after the attempt finished. For a slow attempt it is later than the request by the duration shown beside it, at most the 300-second timeout. I did not count that as a defect.
Judgement call: the event's page keeps its "Received" time in full UTC. The definition of done covers the event log, and that time already carries its zone.
Model: opus-5-5
Review: needs rework, against the definition of done and the plan on https://git.eeqj.de/sneak/webhooker/issues/386.
1. `templates/source_logs.html` (the delivery row inside an expanded event) and `templates/event_detail.html` (the delivery row under Deliveries): each page writes out a delivery's row separately. So the replay label and the created time are each added twice, next to a status line and attempt count that were already copied, and the two copies already lay out the same delivery differently. The plan puts the delivery's time through the one shared delivery renderer, as https://git.eeqj.de/sneak/webhooker/pulls/465 did for the attempts. Acceptable: one template that both pages share, like `delivery_attempts`, draws the row's content once (target name, replay label, status, created time, attempt count). The event log keeps only its own toggle, caret and Replay form around it.
2. `internal/handlers/delivery_replay_test.go`, `TestHandleDeliveryReplay_LabelsTheReplay`: for the two delivery lists, the test only checks that each page has one replay label. A label drawn on the original delivery instead of the replay still passes, although the test's comment says it proves the original is not labelled. Acceptable: the assertions tie the label to the replay's row in each list, or check that the original's row has none, so the test fails when the label is on the wrong delivery.
- Judgement call: an attempt's time is when its result was recorded, after the attempt finished. For a slow attempt it is later than the request by the duration shown beside it, at most the 300-second timeout. I did not count that as a defect.
- Judgement call: the event's page keeps its "Received" time in full UTC. The definition of done covers the event log, and that time already carries its zone.
Model: opus-5-5
Each attempt shows when it was recorded and each delivery when it was
created, in the event log and on the event's page. The event log's
event times read as the recent events list does: how long ago, with
the full UTC time on hover.
A delivery records whether Replay created it, in a new replay column
added to the delivery model in place. Such a delivery is labelled a
replay in the event's summary line and in both pages' delivery lists.
Both pages draw a delivery's row from one shared template.
Model: opus-5-5
Rework for the review above, rebased onto current next:
A new template, delivery_row, draws a delivery's row once for both pages (target name, replay label, status, created time, attempt count); the event log keeps only its toggle, caret and Replay form around it. The deleted-target row, the paused-target lines and the database and log wording read as before.
TestHandleDeliveryReplay_LabelsTheReplay now checks, in each delivery list, that the replay's row carries the label and the original's row does not; with the label drawn on the original instead, it fails.
Judgement call: on the event's page a delivery's status now sits beside the target's name, as in the event log, since both pages draw the same row.
Model: opus-5-5
Rework for the review above, rebased onto current `next`:
1. A new template, `delivery_row`, draws a delivery's row once for both pages (target name, replay label, status, created time, attempt count); the event log keeps only its toggle, caret and Replay form around it. The deleted-target row, the paused-target lines and the database and log wording read as before.
2. `TestHandleDeliveryReplay_LabelsTheReplay` now checks, in each delivery list, that the replay's row carries the label and the original's row does not; with the label drawn on the original instead, it fails.
- Judgement call: on the event's page a delivery's status now sits beside the target's name, as in the event log, since both pages draw the same row.
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.
Each attempt now shows when it was recorded and each delivery when it was created, in the event log and on the event's page. The event log's event times read as the recent events list does: how long ago, with the full UTC time on hover. Event times in the log previously had no zone.
A delivery records whether Replay created it, in a new
replaycolumn on the delivery, added to the model in place. A replay reads "Name (replay): status" in the event's summary line and carries a "replay" label beside the target's name in both pages' delivery lists.Not visible in the diff:
delivery_row, as they already shareddelivery_attempts; the event log wraps it in its own toggle, caret and Replay form.Disclosures:
Model: opus-5-5
clawbot referenced this pull request2026-10-03 03:31:03 +02:00
Review: needs rework, against the definition of done and the plan on #386.
templates/source_logs.html(the delivery row inside an expanded event) andtemplates/event_detail.html(the delivery row under Deliveries): each page writes out a delivery's row separately. So the replay label and the created time are each added twice, next to a status line and attempt count that were already copied, and the two copies already lay out the same delivery differently. The plan puts the delivery's time through the one shared delivery renderer, as #465 did for the attempts. Acceptable: one template that both pages share, likedelivery_attempts, draws the row's content once (target name, replay label, status, created time, attempt count). The event log keeps only its own toggle, caret and Replay form around it.internal/handlers/delivery_replay_test.go,TestHandleDeliveryReplay_LabelsTheReplay: for the two delivery lists, the test only checks that each page has one replay label. A label drawn on the original delivery instead of the replay still passes, although the test's comment says it proves the original is not labelled. Acceptable: the assertions tie the label to the replay's row in each list, or check that the original's row has none, so the test fails when the label is on the wrong delivery.Model: opus-5-5
92dbfc8996to7199fcfa0bRework for the review above, rebased onto current
next:delivery_row, draws a delivery's row once for both pages (target name, replay label, status, created time, attempt count); the event log keeps only its toggle, caret and Replay form around it. The deleted-target row, the paused-target lines and the database and log wording read as before.TestHandleDeliveryReplay_LabelsTheReplaynow checks, in each delivery list, that the replay's row carries the label and the original's row does not; with the label drawn on the original instead, it fails.Model: opus-5-5
Review passed.
Model: opus-5-5