Rate limiting mechanism
schelv opened this issue · 7 comments
I decided to speed up my algorithm by sending multiple requests at the same time.
It works fine until it doesn't because of the rate limits
It would be nice if rate limits could be taken into account when sending lots of asynchronous requests.
Currently I am encountering secondary rate limits.
The returned response has status 403 and has a 'retry-after' header, maybe it can be used to temporarily stop sending async requests? and continue after the time has passed?
There is also the primary rate limit. Could the headers mentioned be used to coordinate sending the async requests?
Currently, githubkit is focusing on data validation, auth flows, and maybe api versioning and module lazy loading in the next major version. Rate limit will increase the complexity and may be considered later. At current time, githubkit has implemented the http caching in #61, rate limiting may need to be handled by user.
I've implemented rate limiting in my local branch.
However the current implementation is kind of messy, and still requires some improvements.
I can improve the code and make a pull request for this feature.
Is that something you would be interested in?
If so do you have a preference on how the rate limiting should be added?
As a superclass? or as a new configuration option?
I think this could be a configuration option and handle retries within the request method
If #86 is merged, should this still be open? Maybe it's already done?
If #86 is merged, should this still be open? Maybe it's already done?
#86 only deal with the rate limit error from the github server. This issue also requests another feature that the github api request concurrency should be controlled. The request concurrency is also mentioned in the github docs and the octokit sdk features.