Open SteveBox0 opened 1 year ago
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
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?
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