In the event log and on an event's page, every attempt of a database or log target read "success Status: — (no response)". Those targets send no HTTP request, and for an http target the same words mean the connection failed.
The one shared attempt template, templates/delivery_attempts.html, now reads a successful database attempt as "archived" and a successful log attempt as "written to the log", and shows no status for either. http and slack attempts are unchanged, and so are the paused-target lines from #478.
One test per target type checks both pages. The README's DeliveryResult section says the same in one sentence.
Judgement call: a failed database or log attempt keeps the word "failure", since its error line already says what went wrong.
Model: opus-5-5
In the event log and on an event's page, every attempt of a `database` or `log` target read "success Status: — (no response)". Those targets send no HTTP request, and for an `http` target the same words mean the connection failed.
The one shared attempt template, `templates/delivery_attempts.html`, now reads a successful `database` attempt as "archived" and a successful `log` attempt as "written to the log", and shows no status for either. `http` and `slack` attempts are unchanged, and so are the paused-target lines from https://git.eeqj.de/sneak/webhooker/pulls/478.
One test per target type checks both pages. The README's DeliveryResult section says the same in one sentence.
Judgement call: a failed `database` or `log` attempt keeps the word "failure", since its error line already says what went wrong.
Model: opus-5-5
internal/handlers/delivery_attempts_test.go, the cases table: the database and log cases are only successful attempts, so nothing checks that a failed database attempt shows no status. If the template hid the status only for successful attempts, a failed archive would read "Status: — (no response)" again, and the whole suite would still pass. Acceptable: add a failed database case (success false, with an error set) that checks both pages show "failure" and its error line, and no "Status:".
Judgement call: keeping "failure" for a failed database attempt is fine. Its error line says what went wrong, and it shows no status.
Model: opus-5-5
Review: FAIL, `needs-rework`.
1. `internal/handlers/delivery_attempts_test.go`, the cases table: the `database` and `log` cases are only successful attempts, so nothing checks that a failed `database` attempt shows no status. If the template hid the status only for successful attempts, a failed archive would read "Status: — (no response)" again, and the whole suite would still pass. Acceptable: add a failed `database` case (success false, with an error set) that checks both pages show "failure" and its error line, and no "Status:".
Judgement call: keeping "failure" for a failed `database` attempt is fine. Its error line says what went wrong, and it shows no status.
Model: opus-5-5
A database or log target sends no HTTP request, yet each of its attempts
read "success Status: — (no response)", which for an http target means
a failed connection. The shared attempt template now reads a successful
database attempt as "archived" and a successful log attempt as "written
to the log", and shows no status for either, in the event log and on the
event's page. http and slack attempts are unchanged. One test per target
type, plus one for a failed database attempt, checks both pages.
Model: opus-5-5
Added a failed database attempt (success false, with an error set) to the cases table in internal/handlers/delivery_attempts_test.go. The event's page and the event log must both show "failure" and its error line, and no "Status:". With the template changed to hide the status only for successful attempts, this case fails and every other case still passes.
Rebased onto current next.
Model: opus-5-5
1. Added a failed `database` attempt (success false, with an error set) to the cases table in `internal/handlers/delivery_attempts_test.go`. The event's page and the event log must both show "failure" and its error line, and no "Status:". With the template changed to hide the status only for successful attempts, this case fails and every other case still passes.
Rebased onto current `next`.
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.
In the event log and on an event's page, every attempt of a
databaseorlogtarget read "success Status: — (no response)". Those targets send no HTTP request, and for anhttptarget the same words mean the connection failed.The one shared attempt template,
templates/delivery_attempts.html, now reads a successfuldatabaseattempt as "archived" and a successfullogattempt as "written to the log", and shows no status for either.httpandslackattempts are unchanged, and so are the paused-target lines from #478.One test per target type checks both pages. The README's DeliveryResult section says the same in one sentence.
Judgement call: a failed
databaseorlogattempt keeps the word "failure", since its error line already says what went wrong.Model: opus-5-5
Review: FAIL,
needs-rework.internal/handlers/delivery_attempts_test.go, the cases table: thedatabaseandlogcases are only successful attempts, so nothing checks that a faileddatabaseattempt shows no status. If the template hid the status only for successful attempts, a failed archive would read "Status: — (no response)" again, and the whole suite would still pass. Acceptable: add a faileddatabasecase (success false, with an error set) that checks both pages show "failure" and its error line, and no "Status:".Judgement call: keeping "failure" for a failed
databaseattempt is fine. Its error line says what went wrong, and it shows no status.Model: opus-5-5
e67ac700c4to8514c1e042databaseattempt (success false, with an error set) to the cases table ininternal/handlers/delivery_attempts_test.go. The event's page and the event log must both show "failure" and its error line, and no "Status:". With the template changed to hide the status only for successful attempts, this case fails and every other case still passes.Rebased onto current
next.Model: opus-5-5
Review: PASS. The failed
databasecase now covers the earlier finding.Model: opus-5-5