-
Notifications
You must be signed in to change notification settings - Fork 6
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
Implement rate limit handling #238
base: master
Are you sure you want to change the base?
Conversation
@itsdalmo I might be a bit pre-emptive in my implementation here, I'll see if we can mock and test this behavior later, do you have an idea on how to proceed? |
OMG, we just hit this today, 👍 for posting this patch! |
@d Please lock down to |
We started hitting this on Thursday, and there's been ongoing report from the community about this as well. While upstream is figuring out a long term solution [1], we've been advised [2] to pin to the previous release (v0.21.0) to avoid being blocked for hours at once. [1]: telia-oss/github-pr-resource#238 [2]: telia-oss/github-pr-resource#238 (comment)
I think the change here looks reasonable, but considering that we are hitting the abuse rate limit I take that as an indication that we are doing something we should not be doing here. Looking at the diff between v0.21.0 and v0.22.0 I noticed this line. I.e., when fetching pull requests we no longer filter out only those that are open but instead we always fetch everything, which for repositories with a lot of history and activity will always result in hitting a rate limit no matter how many times we retry. As such, I think think the best fix here is to either roll back the change I linked above or to do the filtering in the GraphQL query (instead of fetching everything and then filtering in the resource as is currently done). And I suggest we try that before implementing a silent retry for rate limit errors 🤔 |
While working on updating #189 and testing it I ran into this exact issue and @itsdalmo hit the nail on the head. Whereas before on initial fetch of PRs to filter on we only queried for |
We started hitting this on Thursday, and there's been ongoing report from the community about this as well. While upstream is figuring out a long term solution [1], we've been advised [2] to pin to the previous release (v0.21.0) to avoid being blocked for hours at once. [1]: telia-oss/github-pr-resource#238 [2]: telia-oss/github-pr-resource#238 (comment) (cherry picked from commit f4bf9be)
We started hitting this on Thursday, and there's been ongoing report from the community about this as well. While upstream is figuring out a long term solution [1], we've been advised [2] to pin to the previous release (v0.21.0) to avoid being blocked for hours at once. [1]: telia-oss/github-pr-resource#238 [2]: telia-oss/github-pr-resource#238 (comment) Co-authored-by: Jesse Zhang <[email protected]>
Implements a rate-limit function to support #233 and resolve #237
implemented as
in related GitHub v3 API requests.