Webhook retries now span about 3 days
A failed webhook delivery is now retried 7 times over about 3 days instead of for about a minute, so a short outage of your endpoint no longer loses events.
Until now a delivery that failed was retried 5 times in quick succession, and every attempt was over about 75 seconds after the first. An endpoint that was down for a deploy or an afternoon missed the events of that window for good, unless you replayed them.
Failed deliveries now follow a fixed schedule with few attempts, spread out: 7 attempts in total, the last one about 3 days after the first. Sandbox deliveries use only the first 3, so testing never leaves an event waiting for days.
Nothing changes in what BeeL. sends. Receivers must stay idempotent on BeeL-Event-Id, as always: a slow endpoint that processed an attempt but answered too late can still receive the same event again.
What else changed
- The schedule: the first attempt right away, then 1 minute, 10 minutes, 1 hour, 6 hours, 24 hours and 36 hours after the previous one. Every attempt is signed afresh and carries the same
BeeL-Event-IdandIdempotency-Key. - Sandbox: immediately, then +1 minute and +10 minutes, and no more.
- Deliveries already waiting for a retry when this ships keep their 5 attempts and move to the new waits, so their last attempt goes out about 7 hours after the first.
- What is retried is unchanged: network errors, timeouts,
408,429and5xx. Any other4xxis still not retried. - A delivery counts as failed later. The health of a subscription counts a delivery once it has used all its attempts, so the email about an endpoint that stops answering comes no earlier than about 3 days after its first lost event. A
4xxthat is not retried still counts at once. - Pausing, turning off or deleting a subscription drops its pending retries. They are not sent if you reactivate it before their turn; they stay in the delivery log for a manual retry.
- For longer outages, retry from the delivery log or reconcile from the resources, as before. A manual retry has no age limit while the subscription exists.
Where to go next
CLI 0.3.0: commands follow the routes under the NIF
CLI 0.3.0 calls only the routes that name the company, so most commands change name: `beel companies list-invoices <company_id>` is now `beel invoices list`.
A recurring template's history lists what did not happen too
The history now includes failed runs, skipped periods and pauses, each with a `type`. For those entries `invoice_id` is `null`.