Exceeding a secondary rate limit even with 10.0.7 #867
Comments
|
Hmm it's a bummer that the "secondary rate limits" can be have many causes, it's what was previously referred to as abuse limit. We won't be able to 100% avoid them, but there are more things we can do to prevent them. But first thing of business is to make sure we log out the full error object |
|
Hey, actually I removed part of the error as I thought it wasn't meaningful, but I guess I was wrong heh. The Here is the full error log with the 2 objects: |
|
Great, thanks @victor-keltio But, this does look like it's still making a request to the Github Issue Search Rest API 🤔 What'd you think @gr2m!? |
This request is sent to check if an open issue created by semantic-release exists. Either to close it if the releases succeeded or to avoid creating duplicated issues if one already exists. But it's only one request, it's interesting that this one got rate limited. Can you tell me the |
|
Hey, indeed: Thanks a lot for your work and your help :) |
this avoids running into rate limits, see: semantic-release/github#867
|
Just encountered this same thing. Did you discover anything interesting, or whether this even has anything to do with the library?
|
|
Same here https://github.com/containerbase/base/actions/runs/10198110677/job/28213149459 5088:A2DF4:628C6E:BDFEB0:66AB82C4 |
|
@travi moving the convo here. Looks like the details do line up.
My x-github-request-id if it's useful. TIA 😄 |
|
Hey @brandon-kyle-bailey, the issue you've got... Does it relate to this specific one?? 🤔 |
|
again: |
|
just hit this situation again when releasing this plugin: https://github.com/semantic-release/github/actions/runs/10324510144/job/28584116021 |
What a bummer right there @travi, just talked about this with @gr2m few hours ago. We talked about this considering the @tmelliottjr/octokit-plugin-unique-issue approach to creating and retrieving the semantic-releases fails issues via a "unique identifier"... that way we're not searching for issues by title... but even this particular plugin uses the troublesome GitHub SearchAPI itself 🤦 But, what if we can fork and maintain a variant of it that uses GraphQL to atleast fetch opened issues that meet a certain condition confirming its a semantic-release failing relevant issue 🤔... {
repository(owner: "OWNER", name: "REPO") {
issues(first: 100, states: OPEN, filterBy: {labels: "semantic-release-failing-release"}) {
nodes {
title
bodyText
}
}
}
}...then we can get look for the unique identify in the body if we have to or just deal direct with the response node and close 🤔 |
|
One thing we could / should do is to not treat an error from the Also if we don't do so yet, we should send the
I like the idea of using an additional label a lot. I would pivot to only use that approach and get rid of the using the search API altogether as it keeps giving us grievance. |
|
🎉 This issue has been resolved in version 10.3.5 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Hey there, I saw that a recent release was made to use GraphQL instead of Github's API to avoid hitting the rate limits.
I bumped my
@semantic-release/githubversion to use^10.0.7but even with this, I'm hitting the limits:Is there anything I can do to fix this? I've tried releasing a new version after having waited 10min, but I faced the same issue.
Many thanks for your work and your help :)
The text was updated successfully, but these errors were encountered: