Use one recovery routine at start and on every sweep tick (closes #542)
check / check (push) Waiting to run
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:
@@ -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,
|
||||
|
||||
Reference in New Issue
Block a user