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.
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.
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.
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. |
No description provided.