Webhook providers should retry temporary receiver failures without hammering an unhealthy endpoint forever. A useful retry policy distinguishes transient HTTP results, grows delays exponentially, respects a receiver's Retry-After instruction, and stops after a finite number of total attempts.
Design a WebhookRetryPolicy class:
WebhookRetryPolicy(int baseDelay, int maxDelay, int maxAttempts) stores the policy in seconds.int nextAttempt(int failedAt, int attemptNumber, int statusCode, int retryAfter) returns the next attempt timestamp, or -1 when no retry should occur.
Retry status 408, status 429, and every status from 500 through 599. All other statuses are final. attemptNumber counts the failed call and begins at 1; when attemptNumber >= maxAttempts, the total-attempt budget is exhausted.
The exponential delay for attempt k is baseDelay * 2^(k - 1), capped at maxDelay. retryAfter = -1 means no header was supplied. Otherwise use the greater of the capped backoff and retryAfter. The backoff cap does not shorten a larger Retry-After value.
Example 1:
Input:
Output:
Explanation: Attempt 3 would back off for 20 seconds, but the receiver requests 30. Status 400 is final, and attempt 5 uses the last allowed attempt.
Example 2:
Input:
Output:
Explanation: Exponential backoff caps at 25, but the 40-second receiver instruction is still honored.
Constraints
1 <= baseDelay <= maxDelay <= 10^91 <= maxAttempts <= 311 <= attemptNumber <= 31100 <= statusCode <= 999retryAfter is -1 or a non-negative number of seconds.- Any returned timestamp fits a signed 32-bit integer.
- At most
10^5 calls are made to nextAttempt.
Schedule Webhook Retriesmedium