🛡️ Sentinel: Stop retrying on 4xx client errors#188
Conversation
Previously, `_retry_request` would retry on any `httpx.HTTPError`, including 4xx client errors (e.g., 400 Bad Request, 401 Unauthorized). This is inefficient and can lead to API spamming or bans. This change modifies `_retry_request` to: - Check if the exception is an `httpx.HTTPStatusError`. - If the status code is 4xx (and not 429 Too Many Requests), raise the exception immediately instead of retrying. - Log the response content (sanitized) for debugging before raising. This improves security by preventing potential DoS-like behavior against the API and failing fast on invalid inputs or auth failures. Co-authored-by: abhimehro <84992105+abhimehro@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
|
Merging to
|
|
👋 Development Partner is reviewing this PR. Will provide feedback shortly. |
Summary of ChangesHello @abhimehro, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the application's robustness by modifying the retry logic for HTTP requests. It introduces a specific condition to prevent automatic retries for most 4xx client errors, ensuring that issues originating from incorrect client requests are not repeatedly attempted, thereby optimizing resource usage and preventing unintended API interactions. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a valuable change to stop retrying on 4xx client errors, with the exception of 429 for rate limiting. This is a solid approach to prevent spamming the API with invalid requests and improves error handling efficiency. The implementation is correct. I've added one suggestion to simplify the code by removing a redundant check, which will improve readability.
| if hasattr(e, "response") and e.response is not None: | ||
| log.debug(f"Response content: {sanitize_for_log(e.response.text)}") | ||
| raise |
There was a problem hiding this comment.
This check for e.response is redundant. The isinstance(e, httpx.HTTPStatusError) check on line 604 already guarantees that e.response exists and is not None. You can simplify this block by removing the conditional check around the logging statement.
| if hasattr(e, "response") and e.response is not None: | |
| log.debug(f"Response content: {sanitize_for_log(e.response.text)}") | |
| raise | |
| log.debug(f"Response content: {sanitize_for_log(e.response.text)}") | |
| raise |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| status = e.response.status_code | ||
| if 400 <= status < 500 and status != 429: | ||
| if hasattr(e, "response") and e.response is not None: | ||
| log.debug(f"Response content: {sanitize_for_log(e.response.text)}") |
Check notice
Code scanning / Pylintpython3 (reported by Codacy)
Use lazy % formatting in logging functions Note
There was a problem hiding this comment.
Pull request overview
This PR updates the shared HTTP request retry helper to avoid retrying on non-rate-limit client errors, reducing unnecessary repeated requests when failures are permanent (e.g., auth/validation issues).
Changes:
- Add a fast-fail path in
_retry_request()for HTTP 4xx responses (except 429), immediately re-raising instead of retrying. - Log sanitized response content on these non-retriable 4xx failures for debugging consistency with the final-attempt logging.
| # Security: Don't retry on client errors (4xx) unless it's rate limiting (429) | ||
| if isinstance(e, httpx.HTTPStatusError): | ||
| status = e.response.status_code | ||
| if 400 <= status < 500 and status != 429: | ||
| if hasattr(e, "response") and e.response is not None: | ||
| log.debug(f"Response content: {sanitize_for_log(e.response.text)}") | ||
| raise |
There was a problem hiding this comment.
This change introduces new retry behavior (do not retry 4xx except 429), but there doesn't appear to be a test asserting the retry count/behavior for (a) a non-429 4xx (should call the request func once) and (b) 429 (should still retry). Adding focused unit tests around _retry_request for these status codes will prevent regressions.
| status = e.response.status_code | ||
| if 400 <= status < 500 and status != 429: | ||
| if hasattr(e, "response") and e.response is not None: | ||
| log.debug(f"Response content: {sanitize_for_log(e.response.text)}") |
There was a problem hiding this comment.
In the HTTPStatusError branch, e.response is accessed to read status_code before the hasattr(e, "response") / e.response is not None guard. That guard is therefore ineffective (and redundant for HTTPStatusError, which always carries a response from raise_for_status()). Consider removing the guard here, or moving the response existence check before reading status_code (e.g., via getattr(e, "response", None)).
| status = e.response.status_code | |
| if 400 <= status < 500 and status != 429: | |
| if hasattr(e, "response") and e.response is not None: | |
| log.debug(f"Response content: {sanitize_for_log(e.response.text)}") | |
| # Use getattr to avoid AttributeError if a HTTPStatusError ever lacks a response | |
| response_obj = getattr(e, "response", None) | |
| status = response_obj.status_code if response_obj is not None else None | |
| if status is not None and 400 <= status < 500 and status != 429: | |
| if response_obj is not None: | |
| log.debug( | |
| f"Response content: {sanitize_for_log(response_obj.text)}" | |
| ) | |
| # Don't retry non-rate-limited client errors |
|
Closing: superseded by #191 (4xx retry behavior fixed). |
Understood. I will stop working on this task as it has been superseded. |
Stopped retrying on 4xx errors (except 429) to prevent API spamming and improve error handling efficiency.
PR created automatically by Jules for task 9233204614472082297 started by @abhimehro