JasonEtco / create-an-issue

A GitHub Action for creating a new issue from a template file.
MIT License
258 stars 83 forks source link

Error: You have exceeded a secondary rate limit. Please wait a few minutes before you try again. #142

Open SteveBox0 opened 1 year ago

SteveBox0 commented 1 year ago

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

ℹ  info      Fetching issues with title "**************"
Error: You have exceeded a secondary rate limit. Please wait a few minutes before you try again.
✖  fatal     HttpError: You have exceeded a secondary rate limit. Please wait a few minutes before you try again. 
    at /tmp/github-runner-your-repo/_actions/JasonEtco/create-an-issue/v2/dist/index.js:5855:21
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async createAnIssue (/tmp/github-runner-your-repo/_actions/JasonEtco/create-an-issue/v2/dist/index.js:37606:32)
SteveBox0 commented 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.

JasonEtco commented 1 year ago

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.

SteveBox0 commented 1 year ago

@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.

OneCyrus commented 1 year ago

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.

saerosV commented 1 year ago

Happens to me as well, on GitHub-hosted runners.

jgabuya commented 1 year ago

hey everyone, is there any workaround for this? having the same issue on a github-hosted runner

saerosV commented 1 year ago

@jgabuya usually just waiting for a while and re-running the job or triggering a new one works for me.

jeremycarroll commented 1 year ago

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

theofficialgman commented 3 months ago

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

rtrindvg commented 3 months ago

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?