STL-2767: Retry on HTTP 429 with Retry-After support#1631
Open
roman-kiselevich wants to merge 1 commit into
Open
STL-2767: Retry on HTTP 429 with Retry-After support#1631roman-kiselevich wants to merge 1 commit into
roman-kiselevich wants to merge 1 commit into
Conversation
roman-kiselevich
requested review from
hkad98,
jaceksan,
lupko and
pcerny
as code owners
roman-kiselevich
force-pushed
the
rkis/STL-2767-retry-on-429
branch
2 times, most recently
from
b298892 to
778ba64
Compare
Adds GoodDataApiClientRetryConfig, applied to both the generated api-client (via Configuration.retries) and the direct requests.post in _do_post_request (via a Session with HTTPAdapter). Defaults: 10 retries on 429, backoff_factor=0.5, backoff_max=60s; Retry-After honoured automatically. jira: STL-2767 risk: low
roman-kiselevich
force-pushed
the
rkis/STL-2767-retry-on-429
branch
from
778ba64 to
a191652
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
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.
Problem
The public rate limits for the metadata-api provisioning APIs (STL-2767) are now rolled out in
gitops-panther. The gateway responds with HTTP 429 and aRetry-Afterheader when a limit is exceeded, but the Python SDK has no retry handling — every 429 surfaces as anApiExceptionto the caller.Summary
Adds
GoodDataApiClientRetryConfigand applies the sameurllib3.Retrypolicy to both transport paths:gooddata-api-client— viaConfiguration.retries.requests.postinGoodDataApiClient._do_post_request— via aSessionwithHTTPAdaptermounted using the sameRetryobject.Defaults: 10 retries on 429 across GET/HEAD/OPTIONS/TRACE/POST/PUT/PATCH/DELETE,
backoff_factor=0.5,backoff_max=60s.Retry-Afteris honoured automatically by urllib3 when present; backoff only applies when the server omits the header.The config is exposed at the top level (
from gooddata_sdk import GoodDataApiClientRetryConfig) and accepted by bothGoodDataApiClient.__init__andGoodDataSdk.create.Reasoning
The retry policy lives in the hand-written SDK wrapper (
packages/gooddata-sdk/src/gooddata_sdk/client.py) rather than in the auto-generatedgooddata-api-client/, because the latter is regenerated from OpenAPI templates and any direct edits would be overwritten.Configuration.retriesis the documented hook the generator exposes for exactly this purpose.POST/PUT/PATCH/DELETE are included in
allowed_methodsbecause the rate-limited endpoints are provisioning calls — retrying them is safe since the gateway returns 429 before the request is processed.