Use one recovery routine at start and on every sweep tick (closes #542)
check / check (push) Waiting to run

Start-up recovery and the 60-second sweep were two parallel sets of
functions doing the same job. recoverDeliveries now does it, run once at
start and then on every tick from one goroutine. A retrying delivery is
scheduled after what is left of its backoff, now if nothing is left, so
backoffElapsed is gone. The run at start still takes every pending
delivery and opens a webhook database whose file is missing; a tick
still takes only pending deliveries untouched for 15 minutes, at most
500, and skips a missing file. A retrying delivery is taken before its
event is read. The README describes one routine.

Model: opus-5-5
This commit is contained in:
2026-10-15 19:36:34 +00:00
committed by sneak
parent 0cdda43e6c
commit 7eba0d59f5
16 changed files with 705 additions and 594 deletions
+9 -18
View File
@@ -13,8 +13,8 @@ import (
// The engine provides one to each target so a target can own
// its retries durably: it records the attempt, marks the
// delivery retrying, and asks the Scheduler to deliver the
// next attempt after delay — exactly what the engine does for
// its own restart recovery.
// next attempt after delay — exactly what the engine's
// recovery routine does for a retrying delivery.
type Scheduler interface {
ScheduleRetry(task Task, delay time.Duration)
}
@@ -45,29 +45,20 @@ type Target interface {
}
// rescheduler is implemented by targets that own durable
// retries. The engine's restart recovery and periodic sweep
// use it to let the target recompute the schedule for an
// orphaned retrying delivery, keeping the retry schedule
// target-owned. Fire-and-forget targets do not implement it
// and their (never-occurring) retrying deliveries are
// skipped.
// retries. The engine's recovery routine uses it to let the
// target recompute the schedule for an orphaned retrying
// delivery, keeping the retry schedule target-owned.
// Fire-and-forget targets do not implement it, and a retrying
// delivery found for one is terminally failed.
type rescheduler interface {
// remainingBackoff returns how long to wait before the
// next attempt of a recovered retrying delivery.
// next attempt of a recovered retrying delivery: zero once
// its backoff has passed.
remainingBackoff(
webhookDB *gorm.DB,
deliveryID string,
attemptNum int,
) time.Duration
// backoffElapsed reports whether the backoff window for
// the last attempt has already passed, so the periodic
// sweep can re-enqueue the delivery now.
backoffElapsed(
webhookDB *gorm.DB,
deliveryID string,
attemptNum int,
) bool
}
// attemptResult is the outcome of a single delivery attempt,