28 lines
1.0 KiB
Markdown
28 lines
1.0 KiB
Markdown
|
---
|
||
|
|
id: "0001"
|
||
|
|
date: 2026-02-10
|
||
|
|
status: Superseded
|
||
|
|
supersedes:
|
||
|
|
superseded-by: "0003"
|
||
|
|
affected-paths: [lib/relay/delivery.rb]
|
||
|
|
affected-components: [delivery, retries]
|
||
|
|
---
|
||
|
|
|
||
|
|
# 0001 — Retry failed deliveries a fixed three times
|
||
|
|
|
||
|
|
## Context
|
||
|
|
|
||
|
|
Early receivers dropped webhooks intermittently; a delivery that fails once usually succeeds on a quick follow-up. We needed some retry behavior before launch and had no data on receiver load patterns yet.
|
||
|
|
|
||
|
|
## Decision
|
||
|
|
|
||
|
|
Failed deliveries are retried exactly three times, one second apart, then reported as failed. The retry count and spacing are constants in lib/relay/delivery.rb.
|
||
|
|
|
||
|
|
## Consequences
|
||
|
|
|
||
|
|
Simple and predictable; transient blips are absorbed. Receivers that are down for more than a few seconds still lose the delivery, and rapid-fire retries add load to a receiver that is already struggling.
|
||
|
|
|
||
|
|
## Alternatives rejected
|
||
|
|
|
||
|
|
No retries rejected: transient network errors were the dominant failure mode in testing. Unbounded retries rejected: a permanently dead endpoint would wedge the queue.
|