| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Long-window usage quota responses cannot succeed before their reset, so retrying them creates repeated requests and leaves sessions waiting unnecessarily.\n\nTreat 5-hour, weekly, and monthly quota 429s as terminal whether the provider exposes the detail in the message or response body. Preserve retries for short-window rate limits.\n\nFixes anomalyco#39790
|
The following comment was made by an LLM, it may be inaccurate: Based on my search, I found one potentially related open PR: Related PR (not a duplicate):
The current PR (#39791) is specifically about stopping retries for fixed-window usage quotas where retry is futile, whereas #38958 focuses on capping the total number of retries across all scenarios. No duplicate PRs found |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Issue for this PR
Closes #39790
Type of change
What does this PR do?
Stops retrying 429 responses for known long-window usage quotas (5-hour, weekly, or monthly) because another request cannot succeed before the reset. The check uses both the provider message and retained response body.
Short-window rate limits continue through the existing retry path. This complements the general retry cap proposed in #38958 by ending known terminal quota responses immediately.
How did you verify your code works?
The regression tests cover the observed 5-hour response, quota text retained only in responseBody, and a per-minute quota that must remain retryable.
Screenshots / recordings
N/A
Checklist