You have exceeded a secondary rate limit.

[cevich]

Ref: #35

Myself and at least one other person (see issue above) are experiencing errors similar to:

Run dessant/lock-threads@v5
Request quota exhausted for request GET /search/issues
Retrying after 60 seconds
Request quota exhausted for request GET /search/issues
Retrying after 60 seconds
Request quota exhausted for request GET /search/issues
Retrying after 60 seconds
Request quota exhausted for request GET /search/issues
Error: You have exceeded a secondary rate limit. Please wait a few minutes before you try again. If you reach out to GitHub Support for help, please include the request ID 2140:304D7E:25F0EC8:39D31AE:66

The docs on the topic unfortunately include "undisclosed reasons" as a possible cause. At one point it seemed that staggering the job (across multiple repos) was helpful, but that may no longer work. The log above suggests perhaps the issue could be related to excessive GET attempts.

[pbatard]

I'm experiencing the same issue and I have contacted GitHub support about this, who sent me this reply:

Based on your workflow file, it looks like your token authentication doesn't follow the correct syntax we have in our guidelines. If you want to authenticate the workflow using the default GITHUB_TOKEN, I'd recommend following the examples we give in our documentation on Automatic token authentication. But note that API requests authenticated using the default GITHUB_TOKEN have a rate limit of 1,000 requests/hour across all of your repositories.

To work around this limitation, you could also consider authenticating your workflows as a GitHub App.

So, according to GitHub support, using:

        with:
          github-token: ${{ github.token }}

as described in the official documention for lock-threads is wrong and it should instead be something like the following:

        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}

[cevich]

Thanks for investigating this further @pbatard and reporting what you found! I'm alarmed to read "a rate limit of 1,000 requests/hour across all of your repositories". I'm seeing this error on org with hundreds of public repos 😢

The docs seem to suggest to me that from the action's PoV, ${{ github.token }} is equivalent to ${{ secrets.GITHUB_TOKEN }} (for a public repo).

In any case, the rate-limit docs I linked at the top do say:

The rate limit for GitHub Apps using an installation access token scales with the number of repositories and number of organization users.

So at least in my case, it sounds like setting up my own App and using its credentials is the best (though tedious) option.

[klaasnicolaas]

Exactly the same problem and suspect that there is a difference between using ${{ github.token }} or ${{secrets.GITHUB_TOKEN}} even though the Github docs indicate that it wouldn't matter.

I've quite some public repositories (+- 30) that use the lock-thread job and will try replacing the token with ${{secrets.GITHUB_TOKEN}} and see if that makes a difference.

[pbatard]

Well, I can tell you that it made no difference on my workflow, as I switched to ${{ secrets.GITHUB_TOKEN }} yesterday and still ran into the issue. So, outside of stating the obvious (that we are hitting a rate limit from GitHub), it looks like the answer I got from support about not using the "correct" syntax is wrong.

The thing is, when I re-ran the workflow manually, it worked, which it wouldn't if it was a mere syntax error.

At this stage, my guess is that there are simply too many people starting a cron workflow at midnight, GitHub time, since most people would have just copied the following:

on:
  schedule:
    - cron: '0 0 * * *'

And of course, when the GitHub servers see a flood of actions being triggered at exactly the same time, it can't cope with them all and has to rate limit, which would also explain why sometimes it works and sometime it doesn't, depending on whether your job is included in the batch GitHub has capability for before it rate limits.

In other words, my advice would be to try changing the cron: '0 0 * * * to a random MM HH time that is not close to midnight and see how it goes. Or you can wait for me to report once I have done this change myself and (in case I don't see the error) waited a few days to confirm that this was indeed the issue.

[klaasnicolaas]

That's strange, because my lock workflows start at 8 am and I still run into many secondary rate limits. At that time it should not be rush hour on the GitHub servers and that somewhat invalidates the idea that that is the cause of the problem.

In addition, I also have a stale workflow that starts at 7 am and uses the syntax for the token as recommended by Github (${{secrets.GITHUB_TOKEN}}) and that never causes any problems 🤔

[cevich]

That's strange, because my lock workflows start at 8 am

A user reported at the end of #35 that a scheduling change was insufficient for them. Perhaps that's only part of the necessary solution. IMHO, from the docs and support reply, it really sounds like setting up your own Github App is maybe also(?) needed.

That or some clever code changes which are well beyond my own ability. Is it possible the action's code really is making a TON of API requests under certain circumstances?

[dessant]

I also doubt that using github.token is the problem, it should provide the same installation access token as secrets.GITHUB_TOKEN. Using a personal access token or the installation access token of a private GitHub app is likely a decent workaround, though these rate limits look like a GitHub API bug.

Even this repository hits secondary rate limits sometimes, and my account has a very low API usage: https://github.com/dessant/lock-threads/actions

It could also be a bug in plugin-throttling, some users have been reporting similar issues: https://github.com/octokit/plugin-throttling.js/issues

[cevich]

Thanks for chiming in @dessant and sharing your ideas and input. Short of bugs and fixes, I'm looking into adding my own github app as a workaround.

Edit: App-based setup and token acquisition w/in workflow.

[pbatard]

Just gonna point out that after changing the cron time to something a lot more random than something that runs on the top of the hour, I have not seen any issue.

It therefore looks pretty clear to me that there are a few too many people running cron jobs at ##:00 (and even more at 00:00) forcing GitHub to rate limit the load on their server. I would therefore advise anyone experiencing this issue to stay well away from using 0 in any of the first 2 numbers on their cron line.

[cevich]

I only have two days worth of experience, but so far after setting up and using a dedicated github App-level token, none of my projects have experienced this error. All my projects are running the action at the exact same time every day. But since it's being re-used across all my repos, I only had to make one workflow change (to obtain the token). In my case, this was easier than updating the cron times in multiple repos.

The deciding factor for me was from the docs:

The rate limit for GitHub Apps using an installation access token scales with the number of repositories and number of organization users.

FWIW, it wasn't hard to setup the App following the docs. So this (possibly in addition to staggering the times?) is likely the ideal workaround. Of course it would be nicer if GitHub provided more actionable feedback on the error and/or fixed whatever (assumed) bug is causing this ☹️

I think unless there's any other feedback, if after a week or so there isn't any new information, I'm okay with closing this issue as "fixed".

[cevich]

After a week of using a token generated at runtime by a dedicated/private Github App, I've observed no new occurrences of this issue.

[pbatard]

Likewise, after a week of using a different cron time than one that sits right at the top of a specific hour, I have observed no new occurrences of this issue. So at least this should provide 2 options to explore, for people facing a similar problem.

[cevich]

Excellent, thanks for the report @pbatard