repo-file-sync-action: Rate limit exceeded during pull-request
🐞 Describe the bug
Appears that when attempting to sync many repos github may throttle the number of pull-requests that can be made and will result in only partially completing the full list.
...
Locally syncing file(s) between source and target repository
Source is directory
Pushing changes to target repository
Creating new PR
Error: You have exceeded a secondary rate limit and have been temporarily blocked from content creation. Please retry your request again later.
Error: HttpError: You have exceeded a secondary rate limit and have been temporarily blocked from content creation. Please retry your request again later.
Repository Info
Slug : client-config
Owner : acme-corp
Https Url : https://github.com/acme-corp/client-config
Branch : master
Locally syncing file(s) between source and target repository
Source is directory
Pushing changes to target repository
Creating new PR
Error: You have exceeded a secondary rate limit and have been temporarily blocked from content creation. Please retry your request again later.
Error: HttpError: You have exceeded a secondary rate limit and have been temporarily blocked from content creation. Please retry your request again later.
Repository Info
Slug : app-config
Owner : acme-corp
Https Url : https://github.com/acme-corp/app-config
Branch : master
Locally syncing file(s) between source and target repository
Source is directory
Pushing changes to target repository
Creating new PR
Error: You have exceeded a secondary rate limit and have been temporarily blocked from content creation. Please retry your request again later.
Error: HttpError: You have exceeded a secondary rate limit and have been temporarily blocked from content creation. Please retry your request again later.
Repository Info
Slug : api-config
Owner : acme-corp
Https Url : https://github.com/acme-corp/api-config
Branch : master
...
...
📚 To Reproduce
Perform many syncs within one of the limits. Could be x per hour or x per minute.
💡 Expected behavior
Either fast-fail and exit non-zero or retry after 5-10 seconds as per some (additional) action input. The action shouldn’t indicate that it was successful if it didn’t actually perform all the updates in the config (sync.yml).
🖼️ Screenshots
notice the matrix shows 12 jobs, but my sync.yml has 20 repos listed.
⚙️ Environment
- Action version: BetaHuhn/repo-file-sync-action@v1.15.0
📋 Additional context
Add any other context about the problem here.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 2
- Comments: 27 (15 by maintainers)
Commits related to this issue
- 🐛 Fix rate limit issue (#132) Fixes #126 — committed to BetaHuhn/repo-file-sync-action by BetaHuhn 3 years ago
Thanks for testing it @raeganbarker!
I will take a look at the annotations issue you mentioned and release the rate limit fix to master tomorrow 👍
This issue has been resolved in version 1.15.2 🎉
To use the latest version, use the Action with the
v1orlatesttag:Sorry this took so long to fix! If you depend on this action or use it in a commercial project, maybe consider sponsoring me on GitHub or supporting me via platforms like Ko-Fi. This keeps me motivated and allows me to spend more time on projects like this, which ultimately benefits you as a user of this action. Thanks!
This looks good on my side! I re-tested with a sync to 11 repos. The sync for the 10th repo initially ran into the GitHub API rate limit and then was handled successfully with the wait/retry logic.
Plus one for this, I just added the action and configured it to sync 12 repos. It succeeded on 10 and failed on the last 2.
So just to summarize my findings:
abuse->secondary ratein their API response which promptedplugin-throttling.jsto update the plugin and release v3.5.2repo-file-sync-actiondidn’t change the plugin usage since v1.7.1, the only change was a version bump of the mentioned plugin to v3.5.2 with v1.13.2That is where I am currently at. If anyone has any ideas, feel free to share them 😃
Ah yeah, thanks @herbaltealeaf, I missed that when looking through the logs. That explains why it worked for @cansavvy but not for me.
@cansavvy, I don’t think you need to rerun it, we can assume it doesn’t work with v1.8.0
OH I see. Well then, unfortunately I won’t be able to test this for you just yet then. Once those PRs are taken care of by the respective owners of those repos, I can try again later. Sorry.
They changed
abusetosecondary rateinternally as GitHub changed the response, but theonAbuseLimitmethod stayed the same.I tried a few older versions of this action and v1.8.0 also fails:
https://github.com/BetaHuhn/gh-repo-automation/runs/4096456566?check_suite_focus=true#step:3:381
You mentioned v1.7.1 works, so the issue must have been introduced with v1.8.0.
To verify this, could you repeat the same run with v1.7.1 and v1.8.0 (only changing the version) @cansavvy ?
That’s the thing, it is still there and wasn’t changed since it was added. The only change was that the plugin used was bumped from 3.5.1 to 3.5.2.
I will revert that change and see if it works after that. The version before that change is v1.13.1.
I’m also encountering this error and I have an interest in getting around it! I think mine worked on 7 repositories before failing. But also I think my trigger may have been too lenient, the sync got triggered 3 times it seemed? https://github.com/jhudsl/DaSL_Course_Template_Bookdown/actions
I don’t know JS but I’m happy to help anyway I can.