Repository navigation
fix(worker): add p-limit to GitHub API calls to avoid overwhelming the node process (or the API rate limits) - #591
Conversation
brianphillips
commented
Oct 31, 2025
- Add a shared p-limit guard to the GitHub fetch helpers so user/org/repo lookups use capped parallelism instead of unbounded Promise.allSettled.
- Introduce a central MAX_CONCURRENT_GITHUB_QUERIES constant (set to 5) with explanatory comment to keep token usage and rate-limit pressure predictable. This setting could be pulled from the configuration file but that is (IMO) not likely something that will need to be tuned.
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Hey @brianphillips thanks for the PR - could you describe the errors you were running into prior to implementing this? Were you hitting rate limits? How many |
Perhaps not a typical use case but I had >1700 repositories in the config and all of them were getting kicked off simultaneously :) The first sign of trouble is a bunch of these warnings (not critical, but a sign that too many things are being done at once): After that, things stall for a bit and then it seems that all of them fail with an error like this: |
3f589b1 to
ebc7a72
Compare
…s (or the API rate limits) If there's a high number of `repos` in the config, it is not productive to try and run all the API requests in parallel.
ebc7a72 to
be92d26
Compare
|
@brianphillips gotcha makes sense - 1700 individual entries in the config is definitely on the edge-case side (hence we have not hit this before). This approach of using p-limit is clean (and applicable to other areas were we are seeing unbounded promises causing problems, #590). This change is applicable to the other code hosts where we are doing concurrent api calls, but I'd say we can put it into a separate PR |
