feat(notify): generic handling of 429 in retrier#5389
Conversation
add generic handling of 429 in retrier. This will allow to remove any handling of 429 in the individual notifiers and instead rely on the retrier to handle it (TBD in follow-up PRs). Signed-off-by: Christoph Maser <christoph.maser+github@gmail.com>
📝 WalkthroughWalkthroughRetry handling now parses ChangesRetry-After-aware retries
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant HTTPResponse
participant Retrier
participant RetryStageExec
participant AttemptTimer
HTTPResponse->>Retrier: provide status and Retry-After header
Retrier-->>RetryStageExec: return retry decision and ErrorWithReason
RetryStageExec->>AttemptTimer: schedule RetryAfter or backoff delay
AttemptTimer-->>RetryStageExec: trigger next attempt
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
notify/notify_test.go (1)
582-617: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd a comment explaining the timing assumption, matching sibling tests.
Unlike
TestRetryStageHonorsRetryAfterandTestRetryStageWithoutRetryAfterUsesExponentialBackoff, this test doesn't document why 2 attempts (and not more) fit in the 200ms window — it relies on the same coupling tobackoff.NewExponentialBackOff()defaults (the secondNextBackOff()call producing a delay that exceeds the remaining budget). A short comment would help future maintainers understand the timing assumption if backoff defaults change.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@notify/notify_test.go` around lines 582 - 617, Add a short comment in TestRetryStageRecalculatesBackoffAfterRetryAfter near the 200ms context timeout or attempt assertions, documenting that the test expects exactly two attempts because the default exponential backoff’s second delay exceeds the remaining timeout budget. Match the wording and placement style used by TestRetryStageHonorsRetryAfter and TestRetryStageWithoutRetryAfterUsesExponentialBackoff.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@notify/util.go`:
- Around line 244-264: Update parseRetryAfter to prevent overflow when
converting integer Retry-After values to time.Duration: validate or clamp secs
before multiplying by time.Second, using the maximum representable duration as
the upper bound. Preserve the existing zero result for absent, invalid, or
past-date values and keep valid in-range delays unchanged.
---
Nitpick comments:
In `@notify/notify_test.go`:
- Around line 582-617: Add a short comment in
TestRetryStageRecalculatesBackoffAfterRetryAfter near the 200ms context timeout
or attempt assertions, documenting that the test expects exactly two attempts
because the default exponential backoff’s second delay exceeds the remaining
timeout budget. Match the wording and placement style used by
TestRetryStageHonorsRetryAfter and
TestRetryStageWithoutRetryAfterUsesExponentialBackoff.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 2c0f3f1a-9692-4b52-8e1f-25a18a89f8e0
📒 Files selected for processing (4)
notify/notify_test.gonotify/retry_stage.gonotify/util.gonotify/util_test.go
Add generic handling of HTTP responses with 429 status code in Retrier. This will allow to remove any handling of 429 in the individual notifiers and instead rely on the Retrier to handle it (TBD in follow-up PRs).
This is a re-implementation of #5088 but only the backend part. It adds a, currently unused, new receiver (
CheckResponse()) tonotifiy.Retrierthat is meant as future replacment for theCheck()receiverPull Request Checklist
Please check all the applicable boxes.
Which user-facing changes does this PR introduce?