fix: handle HTTP 429 responses missing the Retry-After header - #90
Open
ayeshurun wants to merge 1 commit into
Open
fix: handle HTTP 429 responses missing the Retry-After header#90ayeshurun wants to merge 1 commit into
ayeshurun wants to merge 1 commit into
Conversation
Creating a dataflow (and other long-running, throttling-prone operations) could fail with "[UnexpectedError] retry-after" when Fabric returned a 429 without a Retry-After header. The 429 handler read the header via direct subscript, raising a KeyError that escaped the request exception handler and surfaced as an unexpected error. Use the existing get_polling_interval helper, which reads the header case-insensitively and falls back to the default polling interval when it is missing or non-numeric. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: a4b6c3e7-7425-4fa7-9f0a-ac7e87377ee2
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
1 participant
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.
✨ Description of new changes
Summary: Fixes
fab create ... f.dataflow(and other long-running operations) failing withx [UnexpectedError] retry-after.Context: When Fabric throttles a request but returns an HTTP 429 without a
Retry-Afterheader, the rate-limit handler infab_api_client.pyread the header via direct subscript (response.headers["Retry-After"]). Because requests'CaseInsensitiveDictlowercases keys, this raisedKeyError("retry-after"). That error was not caught by therequests.RequestExceptionhandler, so it bubbled up tomain.pyand surfaced as[UnexpectedError] retry-after. Creating a dataflow is a long-running, polling operation that is especially prone to hitting throttling, which is why it reproduced there.The fix reuses the existing
get_polling_interval()helper, which reads theretry-afterheader case-insensitively and falls back to the default polling interval (10s) when the header is missing or non-numeric. This makes the client resilient to throttled 429s and lets it retry as intended instead of erroring out.Dependencies: None.
Testing
test_do_request_429_without_retry_after_header_retries_with_default_interval, verified it reproduces theKeyErroron the old code and passes on the fix.blackandmypyclean.fixedentry.