No replay: a delivery that exhausts max_retries is failed forever, and store-and-forward is the point #203

New Issue

clawbot · 2026-08-20T05:47:22+02:00

clawbot commented

2026-08-20 05:47:22 +02:00

There is no redelivery path anywhere. Grepping replay|redeliver|resend finds one comment, at internal/delivery/engine.go:804, reading "nothing redelivers it today".

Once a delivery reaches max_retries it is failed permanently. The body is durably stored, so the data is right there, but the only way to get it delivered is to download it and re-POST by hand. Storing the event and then being unable to re-send it defeats the reason the event is stored at all: the ordinary real-world case is a destination that was down longer than the backoff ladder.

Definition of done:

a per-delivery replay action on the event log / source detail page, POST with CSRF, available for any terminal delivery
replay creates a NEW delivery row against the current target config and runs it through the normal engine path, retries included; it does not mutate or overwrite the original delivery's history
replaying an event whose target has since been deleted is refused with a clear message rather than erroring
replay is subject to the same SSRF guard and circuit breaker as a first attempt
tests cover: replay of a failed delivery succeeds and appends a new delivery, the original rows are untouched, and replay against a deleted target is refused

Bulk replay of every failed delivery for a source is a plausible follow-up, out of scope here unless it is nearly free.

There is no redelivery path anywhere. Grepping `replay|redeliver|resend` finds one comment, at `internal/delivery/engine.go:804`, reading "nothing redelivers it today". Once a delivery reaches `max_retries` it is `failed` permanently. The body is durably stored, so the data is right there, but the only way to get it delivered is to download it and re-POST by hand. Storing the event and then being unable to re-send it defeats the reason the event is stored at all: the ordinary real-world case is a destination that was down longer than the backoff ladder. Definition of done: - a per-delivery replay action on the event log / source detail page, POST with CSRF, available for any terminal delivery - replay creates a NEW delivery row against the current target config and runs it through the normal engine path, retries included; it does not mutate or overwrite the original delivery's history - replaying an event whose target has since been deleted is refused with a clear message rather than erroring - replay is subject to the same SSRF guard and circuit breaker as a first attempt - tests cover: replay of a failed delivery succeeds and appends a new delivery, the original rows are untouched, and replay against a deleted target is refused Bulk replay of every failed delivery for a source is a plausible follow-up, out of scope here unless it is nearly free.

clawbot added this to the 1.0.0 milestone 2026-08-20 05:47:22 +02:00

clawbot referenced this issue

2026-08-20 05:49:42 +02:00

1.0/mvp #33

clawbot referenced this issue

2026-08-20 05:56:52 +02:00

Milestone 1.0.0: internet-facing readiness #111

clawbot referenced this issue from a commit

2026-08-20 07:49:16 +02:00

Add per-delivery replay to the event log (closes #203)

clawbot referenced a pull request that will close this issue

2026-08-20 07:50:13 +02:00