Add policy to handle Retry-After response headers#1097
Merged
ansasaki merged 6 commits intokeylime:masterfrom Sep 3, 2025
Merged
Add policy to handle Retry-After response headers#1097ansasaki merged 6 commits intokeylime:masterfrom
ansasaki merged 6 commits intokeylime:masterfrom
Conversation
sarroutbi
force-pushed
the
202509011440-add-retry-after-policy
branch
from
4315b9f to
7b6bacb
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
ansasaki
reviewed
Sep 2, 2025
Signed-off-by: Sergio Arroutbi <sarroutb@redhat.com>
- Added a maximum retry attempt limit (MAX_RETRY_AFTER_ATTEMPTS = 5) to prevent infinite retries Signed-off-by: Sergio Arroutbi <sarroutb@redhat.com>
This change refactors the retry mechanism to eliminate the separate, hardcoded retry limit for Retry-After responses. Previously, the client used two different values for maximum retries: a constant for the RetryAfterMiddleware and a parameter for the exponential backoff policy. This could lead to confusing and inconsistent behavior. Now, the RetryAfterMiddleware is initialized with the same max_retries value provided to the ResilientClient constructor, ensuring that both retry strategies (Retry-After headers and exponential backoff) respect a single, unified configuration. Signed-off-by: Sergio Arroutbi <sarroutb@redhat.com>
Signed-off-by: Sergio Arroutbi <sarroutb@redhat.com>
Signed-off-by: Sergio Arroutbi <sarroutb@redhat.com>
Signed-off-by: Sergio Arroutbi <sarroutb@redhat.com>
sarroutbi
force-pushed
the
202509011440-add-retry-after-policy
branch
from
b666abc to
e5a51e7
Compare
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
3 participants
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.
This pull request enhances the ResilientClient by adding support for the standard Retry-After HTTP response header.
Currently, our client relies solely on an exponential backoff strategy for all retryable errors. While effective, this approach is less precise when a server explicitly indicates how long we should wait before trying again (e.g., for rate limiting or temporary maintenance).
This change introduces a dedicated middleware that respects the Retry-After header, making our client a better HTTP citizen and improving its ability to recover from transient server-side issues efficiently.
Co-Authored-By: Gemini noreply@google.com
Co-Authored-By: Claude noreply@anthropic.com
Signed-off-by: Sergio Arroutbi sarroutb@redhat.com