Skip to content

feat(notify): generic handling of 429 in retrier#5389

Open
TheMeier wants to merge 1 commit into
prometheus:mainfrom
TheMeier:429_RateLimitedReason
Open

feat(notify): generic handling of 429 in retrier#5389
TheMeier wants to merge 1 commit into
prometheus:mainfrom
TheMeier:429_RateLimitedReason

Conversation

@TheMeier

@TheMeier TheMeier commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

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()) to notifiy.Retrier that is meant as future replacment for the Check() receiver

Pull Request Checklist

Please check all the applicable boxes.

Which user-facing changes does this PR introduce?

NONE

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>
@TheMeier
TheMeier requested a review from a team as a code owner July 16, 2026 17:31
@coderabbitai

coderabbitai Bot commented Jul 16, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

Retry handling now parses Retry-After from HTTP 429 responses, propagates it through ErrorWithReason, and schedules retries with per-attempt timers. Tests cover explicit retry delays, backoff recalculation, default exponential backoff, response classification, and header parsing.

Changes

Retry-After-aware retries

Layer / File(s) Summary
Response retry contract
notify/util.go, notify/util_test.go
Retrier.CheckResponse classifies responses, parses numeric or HTTP-date Retry-After values for 429 responses, and exposes the delay through ErrorWithReason.RetryAfter; table-driven tests cover response and parsing behavior.
Per-attempt retry scheduling
notify/retry_stage.go, notify/notify_test.go
RetryStage.exec uses resettable timers, honors positive RetryAfter durations, adjusts fallback backoff by failed-attempt duration, and tests explicit, recalculated, and exponential retry timing.

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
Loading
🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 10.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Linked Issues check ✅ Passed The change implements generic 429 retry handling and Retry-After support, matching #2205's retry-improvement goal.
Out of Scope Changes check ✅ Passed All changes stay within notify retry/response handling and related tests, with no unrelated scope added.
Title check ✅ Passed The title is concise and accurately summarizes the main change: generic 429 handling in the retrier.
Description check ✅ Passed The description covers the template sections, checklist items, linked issues, and release notes.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
notify/notify_test.go (1)

582-617: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Add a comment explaining the timing assumption, matching sibling tests.

Unlike TestRetryStageHonorsRetryAfter and TestRetryStageWithoutRetryAfterUsesExponentialBackoff, this test doesn't document why 2 attempts (and not more) fit in the 200ms window — it relies on the same coupling to backoff.NewExponentialBackOff() defaults (the second NextBackOff() 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

📥 Commits

Reviewing files that changed from the base of the PR and between 9e50fad and 1af5b26.

📒 Files selected for processing (4)
  • notify/notify_test.go
  • notify/retry_stage.go
  • notify/util.go
  • notify/util_test.go

Comment thread notify/util.go
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants