-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Primary and secondary rate-limit handling #52
Conversation
👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labled with |
PR Summary
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! ➕ For setting up the infrastructure for the local testing ground as well!
Note that parts of testing code were taken from our colleagues at Kiota (as noted here) and parts of implementation code were taken from the google/go-github library (as noted here). I'm grateful to those teams for doing excellent work before us!
This PR adds a rate limit handler to the go-sdk for primary and secondary rate limits. When it detects such a rate limit, it sleeps until the limit has expired, then retries the request. This has been validated using a local GitHub test environment in addition to unit test coverage. In the future, it would be cool to build better retry logic that builds in exponential backoff, jitter, throttling, etc.
It also greatly simplifies the abstractions for API client instantiation. The values I focused on were:
The current pattern looks like this: