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.