Rate limiting

[steveoh]

This may be something we are experiencing based on the git commit history size of our repo or the amount of activity during our lock window, but this action is failing because it is exceeding github's rate limiting.

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

Can we slow this action down on it's usage of the github api to allow for larger/active repositories to function properly?

[dessant]

You could edit the cron property to reduce the frequency of scheduled runs: https://github.com/dessant/lock-threads#examples

We could intergrate a tool like this to handle rate limiting in the future: https://github.com/octokit/plugin-throttling.js

[steveoh]

This is run daily, 0 7 * * *, so I don't think it's a frequency issue. I think throttling would be a great feature to add.

[steveoh]

Still a common issue for us.

[DaveSkender]

GitHub has some advice on how to actively handle the rate limit. Some options:

• limit to one call per second
• adapt call frequency on error with Retry-After: [delay]

Ref: https://docs.github.com/en/rest/guides/best-practices-for-integrators#dealing-with-secondary-rate-limits

This would have to be done on the internal iterations in this package, so cron won't help much if you have a long history.

[bflad]

This cropped up for us as well on a relatively small issue/PR count repository:

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

The associated workflow configuration:

name: 'Lock Threads'

on:
  schedule:
    - cron: '50 1 * * *'

jobs:
  lock:
    runs-on: ubuntu-latest
    steps:
      - uses: dessant/lock-threads@v3
        with:
          github-token: ${{ github.token }}
          issue-comment: >
            I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.
            If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
          issue-inactive-days: '30'
          pr-comment: >
            I'm going to lock this pull request because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active contributions.
            If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
          pr-inactive-days: '30'

Over in some of my personal and my work's GitHub Actions written in JavaScript, they utilize GitHub's @ockokit/plugin-throttling package to handle retries and throttling logic.

NPM Package: https://www.npmjs.com/package/@octokit/plugin-throttling
Example Implementation: https://github.com/bflad/action-milestone-comment/blob/main/octokit.js

[JC5]

I'm getting daily errors now about the secondary rate limit.

[brenner-tobias]

For me as well, any updates on this?

[bblanchon]

I'm still getting this error with v5

Is there anything I can do to mitigate this issue?

[JC5]

It stopped being an issue for me when I spaced out other recurring actions. So not all actions at exactly midnight. Those other actions were also influencing the rate limit.

Now, with everything an hour apart it works fine.

[bblanchon]

I already spaced out all my recurring actions.
I wondered if the number of issues could be an issue, but I see that firefly-iii has many issues, so that's definitely not the reason.
I also double-checked my Personal Access Token, but I only have one left, and it cannot be the culprit.

[cevich]

I'm encountering this problem on a number of repos (all under one org.) that use this action once per day. Unfortunately the problem is also intermittent. Looking at the docs, I noticed this clause:

"These secondary rate limits are subject to change without notice. You may also encounter a secondary rate limit for undisclosed reasons."

😞

Has spacing out the workflows resolved this issue for anybody else?

[JC5]

Contrary to my earlier reply, spacing out my workflows stopped working. Or perhaps, I was simply lucky.

[cevich]

Thanks for the reply, I was afraid of something like that 😞 Since there was actually a fix applied based on this issue, I think a new issue is warranted.