Repository navigation
Rate limit #201
Description
On many changed files, PR, the action gets into a loop of rate limit errors.
Warning: [@octokit/plugin-throttling] `onAbuseLimit()` is deprecated and will be removed in a future release of `@octokit/plugin-throttling`, please use the `onSecondaryRateLimit` handler instead
{ name: 'octokit' }
Warning: Abuse limit hit with "POST /repos/{owner}/{repo}/pulls/{pull_number}/reviews", retrying in 5 seconds.
It appears that 5-second retries are not sufficient for GitHub to release the rate limit.
My suggestion is to add a comment as soon as every file scan is finished, this way the delay between POSTs will be long enough not to cause this loop.
Activity
anc95 commentedon Jan 4, 2026
it does the way
add a comment as soon as every file scan is finishednow. how many file changes in your commit?kapcod commentedon Jan 4, 2026
anc95 commentedon Jan 11, 2026
hi @kapcod
I was thinking about this for a while. there are two types of rate limit of Github (for your reference https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28#about-secondary-rate-limits), the current implement may hit the secondary rate limit.
first, I need admitted that I said wrong in the first reply, I checked the code, the review only sent once after all files reviewed by GPT (using API https://docs.github.com/en/rest/pulls/reviews?apiVersion=2022-11-28#create-a-review-for-a-pull-request). the api body already contains all comments, so only sent one time, so, in theory, would not hit the primary rate limit.
but as for the secondary limit, there has limit on the content generation, it says
in our case there has 130 files changed, the comment amount may more than 130 (if averagely there are two change chunks per file, then will have 260 comments need to be submitted), I think this might be tagged as
abuse useby GitHub side.Br1an67 commentedon Mar 1, 2026
I'd like to work on this. The fix batches review comments into smaller groups (default 40 per batch with 5s delay) to stay under GitHub's secondary rate limit for content-generating requests.
PR: #206