-
Notifications
You must be signed in to change notification settings - Fork 128
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
API rate limit exceeded for installation #644
Comments
One thing I want to look into is to avoid using search in the first place, we can look up associated pull requests based on commits using GraphQL now, there is no need to use search for that. |
If you need any example failed pipeline you can look into this one. |
I got hit by this issue earlier today and have done some digging to see what is going on. So far there I've found 1 reason that is potentially causing retries to fail: https://github.com/semantic-release/github/blob/v9.0.4/lib/octokit.js#L25-L48 In the setup of the Octokit class, the retry config is passed in via {
// By default, Octokit does not retry on 404s.
// But we want to retry on 404s to account for replication lag.
doNotRetry: [400, 401, 403, 422],
} But in the I tried to write a test to cover off the rate limit scenario, but I also noticed that the |
Here is another failed pipeline, I saw in the logs that the search request was already limited. We use dependabot to keep deps up to date, resulting in a lot of small merge requests. Combined with not so regularly "manual" updates this results in a lot of issues having to be updated after release. But before at least some issues got updated, now it seems it doesn't even update one issue because searching for affecting issues already fails. Since logs vanish after some time, here is the request from the log
|
@Kampfmoehre your version of Upgrade your version of the package and I suspect it won't happen anymore (I've not experienced any issues since |
@dhensby thx, I'll give it a try. We don't have the plugin as extra dep though, was previously using the one that comes with semantic-release package so you might want to update the min version there. |
The |
I think I'm running into the same problem as @Kampfmoehre and would appreciate some help getting the dependencies upgraded properly. First, here's the error we are seeing:
As you can see, it says we are using However, in the build container we use the dependencies are the following:
We also execute semantic-release with npx as recommended in a previous comment. Given that semantic-release should be using at least version 10.0.0 of @semantic-release/github, I am not sure how v9.2.6 is actually responsible for making the request. I'd appreciate any guidance on what to upgrade in order to use a newer version that has the rate-limiting fix. Thank you! |
@ab-arao you've not run into the same problem as @Kampfmoehre. They ran into the canonical issue of this thread (which is that if the API limit was hit then the job failed immediately). What was meant to happen is that a secondary back-off was meant to take place to try to "wait out" the API limit resetting. Your job has done that (hence the I think it's time this issue was closed, as I believe the issue is fixed. It may be worth a new issue opened about the secondary rate-limit and a more reliable way to wait-out the API limit even more gracefully. |
Got it, thanks for clarifying @dhensby! I agree it makes sense to treat this as a separate issue since now the secondary rate limit is the issue. |
|
@babblebey seems like this is still a problem with the latest
I thought I remember reading that the version is now supposed to use GraphQL to do the issue search instead of the GH API? EDIT: I see the new issue, any update on when a fix will be merged? |
Yea, we changed consumption of the searchAPI in the request to fetch for But, we still use the searchAPI when fetching for semantic-realease created failing release issues, we do this search so we can close the issue on successful release. The searchAPI is very troublesome haha, painful to experience but, we're currently working on a fix here #907 where we're relegating its usage to remove in future release and replace with GraphQL |
I was hoping that rate limiting is now properly taken care of since we moved to Ocotkit via #487, but the error popped up again
https://github.com/semantic-release/commit-analyzer/actions/runs/5159013164/jobs/9293389281#step:6:126
We can tell from the user agent that the correct
@semantic-release/github
version was usedWhat's odd: the
request
option does not have aretries
key, it looks like it didn't attempt to retry at all:https://github.com/semantic-release/commit-analyzer/actions/runs/5159013164/jobs/9293389281#step:6:138
I will look into it. Sorry, I'm not sure why this is happening and rate limit errors are hard to reproduce reliably, it will take me a moment to get to the bottom of this. If anyone is inclined to help out, you are very welcome to
The text was updated successfully, but these errors were encountered: