You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, it's pretty easy to hit a GitHub rate limit when running queries that use the GitHub API tables. We could consider implementing a back-off-retry strategy to pause execution when we encounter one, wait an appropriate amount of time, and retry/continue
The text was updated successfully, but these errors were encountered:
Seconded. I have hit a lot of rate limits and there's definitely opportunity here to know what the existing rate limit is and work with it. I don't think it helps that some queries using the v4 API will eat up a lot more of your quota than an equivalent v3 call. We have a small utility that gathers all the pull requests for a repo, and if you have a highly active one, this seems ideal to leveraging mergestat for. Unfortunately, I haven't been able to find a magic combination on the GITHUB_PER_PAGE and GITHUB_RATE_LIMIT variables that doesn't eventually end up in a timeout. I can get further, but never all the results, and it takes a LOT longer than an equivalent REST v3call to the Pulls API.
Currently, it's pretty easy to hit a GitHub rate limit when running queries that use the GitHub API tables. We could consider implementing a back-off-retry strategy to pause execution when we encounter one, wait an appropriate amount of time, and retry/continue
The text was updated successfully, but these errors were encountered: