Repository navigation
Conversation
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
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.
A brief burst of API requests can exhaust a billing account's allowance and make an otherwise valid Notehub command fail with HTTP 429. The hub can return that refusal without a body, leaving legacy commands with a JSON parsing error and little explanation.
This adds automatic 429 retries to the shared authenticated request path used by
notehub apiand the legacy V0/V1 commands. Commands wait for capacity and return the eventual response; persistent throttling produces an error that explains the account's limit when the hub supplies that information.The retry delay follows server guidance in this order:
Retry-Aftervalue, expressed as seconds or an HTTP date.X-RateLimit-LimitandX-RateLimit-Period, orX-RateLimit-Resetwhen that pair is unavailable, with jitter.Each request allows at most six retries within a one-minute budget that includes request time and waits. If the next delay will not fit, the final 429 is returned intact. A server-requested delay is never shortened to fit the budget. This bounds retry scheduling without interrupting an in-flight request or a successful streaming response.
Retries require a replayable request body, continue to use the existing OAuth refresh handling, and respect context cancellation while waiting. For
notehub api, an error message in the final response body takes precedence over the explanation derived from headers.--verbosereports each retry wait on stderr whether the flag appears before or after the API path, and a trailing--verbose=falsesuppresses those messages. The README documents the policy.Validation passed in both the root module and
lib/:GOWORK=off go test -race -count=1 ./...GOWORK=off go vet ./...Tests cover header precedence, body replay, credential renewal, cancellation, exhausted retries, and final-response preservation. Clock-controlled tests verify the total budget without real minute-long waits; subprocess tests exercise CLI startup and flag placement.