Error: You have exceeded a secondary rate limit. Please wait a few minutes before you try again. #142
Comments
|
If you run a simple workflow that has an existing issue already created a few times this issue can be easily replicated. |
|
Thanks for reporting @SteveBox0. Can you be more specific? If you can give clear steps to reproduce it, that'd help a lot in my understanding, as I haven't seen it myself before. |
|
@JasonEtco Apologies for the delay but needed to do some more testing to be 100% sure. From the looks the issue occurs a lot more on self hosted github runners as you can have multiple runners requesting github API from the same IP. While github hosted runners each have a unique IP thus much lower chance of hitting the rate limit. For your own testing i would suggest running up a couple of github runners in docker containers (https://github.com/myoung34/docker-github-actions-runner). Then any simple github workflow with checking if an existing issue already exists should be enough. Run a couple of them around the same time, can be across different repos but with the same runner pool. |
|
we have the same issue in a scheduled workflow every time. it's using a ubuntu-latest runner. So it doesn't matter if selfhosted or not. |
|
Happens to me as well, on GitHub-hosted runners. |
|
hey everyone, is there any workaround for this? having the same issue on a github-hosted runner |
|
@jgabuya usually just waiting for a while and re-running the job or triggering a new one works for me. |
|
A possible way to address this is to use a token from a github app. The rate limits for normal tokens are fairly low. I am unclear whether an app token gets higher secondary limits - the primary limits are a lot higher |
|
Also getting this about 1/5 of the time when using this action. The action runs once every 12 hours so there should not be any ratelimits hit https://github.com/Botspot/pi-apps/actions/runs/8466989961/job/23197549473 |
* Avoid rate limit error on scheduled daily test There appears to be an issue when scanning issues for a matching issue title which triggers a secondary rate limit error. As this is not the primary feature we are using and an optimization, removing this for now See: https://github.com/mlcommons/newhelm/actions/runs/8604877224/job/23579923706 See: JasonEtco/create-an-issue#142
* Avoid rate limit error on scheduled daily test There appears to be an issue when scanning issues for a matching issue title which triggers a secondary rate limit error. As this is not the primary feature we are using and an optimization, removing this for now See: https://github.com/mlcommons/newhelm/actions/runs/8604877224/job/23579923706 See: JasonEtco/create-an-issue#142
* Avoid rate limit error on scheduled daily test There appears to be an issue when scanning issues for a matching issue title which triggers a secondary rate limit error. As this is not the primary feature we are using and an optimization, removing this for now See: https://github.com/mlcommons/newhelm/actions/runs/8604877224/job/23579923706 See: JasonEtco/create-an-issue#142
|
Same error here. It seems to be triggered easily when using the "update_existing: true" parameter, so the search/issues endpoint is the one affected by the secondary rate limit. Any updates on this issue? |
The job sometimes fails because we're hitting a rate limit. Removing `update_existing: true` seems to the main culprit for hitting the rate limit. See JasonEtco/create-an-issue#142 (comment) works on #359
The job sometimes fails because we're hitting a rate limit. Removing `update_existing: true` seems to the main culprit for hitting the rate limit. See JasonEtco/create-an-issue#142 (comment) works on #359
As per Github docs it should retry after a period of time based off the HTTP response header "Retry-After: ".
https://docs.github.com/en/rest/guides/best-practices-for-integrators?apiVersion=2022-11-28#dealing-with-secondary-rate-limits
The text was updated successfully, but these errors were encountered: