Bound the 429 retry and back off exponentially - #70
Open
Pichatorn-A4K wants to merge 1 commit into
Open
Conversation
The rate-limit branch slept a fixed 5 seconds and then re-entered Request() recursively with no attempt ceiling, with a '// TODO - Figure out how long to wait' left in place. DigiCert documents two limits - 1000 requests per 3 minutes and 100 per 5 seconds, rolling, per API key - and recommends exponential backoff with a default maximum of 3 retries. Its 429 responses carry no Retry-After header, so there is nothing to read and the client has to choose the interval. A fixed 5-second wait only clears the burst window, never the 3-minute one, so tripping the larger limit turned into an indefinite 5-second poll with a stack frame per attempt instead of an error the caller could surface. This is easy to trip on a large account: a full synchronization issues roughly four GETs per order plus one per certificate. Now 5s, 10s, 20s, then the 429 body is returned to the caller as an error.
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.
The rate-limit branch slept a fixed 5 seconds and then re-entered Request()
recursively with no attempt ceiling, with a '// TODO - Figure out how long to
wait' left in place.
DigiCert documents two limits - 1000 requests per 3 minutes and 100 per 5
seconds, rolling, per API key - and recommends exponential backoff with a
default maximum of 3 retries. Its 429 responses carry no Retry-After header,
so there is nothing to read and the client has to choose the interval.
A fixed 5-second wait only clears the burst window, never the 3-minute one,
so tripping the larger limit turned into an indefinite 5-second poll with a
stack frame per attempt instead of an error the caller could surface. This is
easy to trip on a large account: a full synchronization issues roughly four
GETs per order plus one per certificate.
Now 5s, 10s, 20s, then the 429 body is returned to the caller as an error.
Found during a pre-engagement audit of the shipped 2.4.1
net8.0assembly; verified by building and running the change against a fake client offline. Companion PRs from the same audit: #65, #66, #67.🤖 Generated with Claude Code