Repository navigation
feature(webhooks): compress in-loop retry backoff so retries start sooner - #250
Merged
Merged
Conversation
…oner Change dispatcher _BACKOFF_SECONDS from (1,5,30,120,600) to (1,5,15,30,60). At the default max_attempts=5 the old schedule pushed the 5th attempt to 156s (a single 120s sleep before it); the new schedule reaches attempt 5 at 51s with no gap over 30s. Update the delivery-semantics doc to match.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A webhook delivery that fails could take 156 s to reach its 5th (final) in-loop attempt. With the default
webhook_max_attempts=5, the old_BACKOFF_SECONDS = (1, 5, 30, 120, 600)schedule meant a single 120 s sleep sat before the last attempt — so any transient backend outage held the envelope for over two minutes before the last try, and only then handed off to the durable backlog.Change
Compress the in-loop schedule to
(1, 5, 15, 30, 60).Full in-loop exhaustion drops from 156 s → 51 s (fast-fail), and no single sleep exceeds 30 s at the default attempt count. The
60tail only comes into play if an operator raiseswebhook_max_attempts.The durable backlog drainer's separate (coarser) schedule is unchanged — rows still only reach it after the in-loop budget is exhausted.
Docs
docs/integration/03-webhooks.md§ Delivery semantics updated to match the new schedule.