-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Rate Limit Handling #2787
Rate Limit Handling #2787
Conversation
@nickfloyd This could be a way of handling rate limits? What do you think? Just thinking out loud here. |
|
||
// Could rate limit refreshes be up to an hour in the future? | ||
// Should we conditionally retry only if it's a short period in the future | ||
if (timeToWait < TimeSpan.FromSeconds(30)) |
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.
This is quite a long time to wait in the case of microservices. Places where I use Octokit would have a request timeout in the region of a few seconds at most, so this would be redundant in those cases as the CancellationToken
would always fire and prevent another attempt ever happening while masking the HTTP request exception from the 403(429?) with a timeout-related exception instead.
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.
Yeah I do agree. From the documentation, unless I'm wrong, it sounded like rate limits reset hourly. In which case this functionality might not be particularly useful as it would very rarely be hit.
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.
Yeah from my experience, once you hit a limit then you just have to wait, unless it's a secondary rate-limit - those reset much sooner (I don't know how often though, I think it's the order of minutes).
I have implemented a leaky bucket type API filter in my own code. Not sure how I would port it over to here but the idea is that you have x number of calls that can be used in y time. Only allow one call per z milliseconds. That way you never really run out and it seems to adhere to the rate AND abuse limits. |
👋 Hey Friends, this pull request has been automatically marked as |
No description provided.