Repository navigation
implement concurrency scheduler for bulkrepo actions - #67
Facelessism wants to merge 1 commit into
Conversation
📝 WalkthroughWalkthroughBulk repository actions now run through a configurable concurrency scheduler. The scheduler bounds parallel workers and preserves result ordering, while ChangesBulk repository concurrency
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant bulkRepoAction
participant runWithConcurrency
participant RepositoryAction
bulkRepoAction->>runWithConcurrency: submit repositories and concurrency
runWithConcurrency->>RepositoryAction: execute bounded worker calls
RepositoryAction-->>runWithConcurrency: return action result
runWithConcurrency-->>bulkRepoAction: return ordered results
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
server/src/utils/githubScheduler.js (1)
35-45: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winWorker errors aren't isolated — in-flight workers keep running after the batch rejects.
If
worker()throws for one item, thatexecuteWorkerloop rejects and propagates throughPromise.all, but the other concurrently-runningexecuteWorkerloops are not stopped — they keep pulling and executing items in the background even though the caller has already received a rejection, and whatever they compute intoresultsis discarded. For a utility meant to be reused across future bulk operations, this means a single failure can silently leave extra in-flight API calls running with no observable outcome, and callers get no partial results on failure.Today
bulkRepoActionguards against this by always catching inside its own worker, but that's an implicit contract this file doesn't document or enforce.♻️ Suggested guard
const executeWorker = async () => { while (true) { const index = nextIndex++; if (index >= items.length) { return; } - results[index] = await worker(items[index], index); + try { + results[index] = await worker(items[index], index); + } catch (error) { + results[index] = { error }; + } } };Alternatively, if throwing is intended to abort the whole batch, document that contract explicitly in the JSDoc so future callers know they must handle their own errors.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@server/src/utils/githubScheduler.js` around lines 35 - 45, Update the worker orchestration around executeWorker and its Promise.all handling so a worker failure signals cancellation to all other in-flight loops and prevents them from pulling or executing additional items. Ensure the batch rejection remains observable to the caller while already-running workers stop cooperatively; alternatively, explicitly document in the relevant JSDoc that worker errors abort the batch and callers must handle worker errors themselves.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@server/src/utils/githubScheduler.js`:
- Around line 35-45: Update the worker orchestration around executeWorker and
its Promise.all handling so a worker failure signals cancellation to all other
in-flight loops and prevents them from pulling or executing additional items.
Ensure the batch rejection remains observable to the caller while
already-running workers stop cooperatively; alternatively, explicitly document
in the relevant JSDoc that worker errors abort the batch and callers must handle
worker errors themselves.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 8d0d81d0-3be3-4ecc-9aa9-2167d47e1724
📒 Files selected for processing (2)
server/src/services/bulkRepoAction.service.jsserver/src/utils/githubScheduler.js
|
@kanak227 :-) |
📝 Description
This PR implements a configurable concurrency scheduler for bulk GitHub operations to improve execution efficiency and reduce the likelihood of API rate-limit issues. Refactored the bulk action service to use a queue-based concurrency mechanisms.
🔗 Related Issue
Closes #66
📂 Type of Change
Please check the relevant option(s):
🧪 How Has This Been Tested?
Describe the tests you ran and the steps to verify your changes.
📸 Screenshots / GIFs (if applicable)
Add screenshots or GIFs to demonstrate UI changes.
✅ Checklist
📌 Additional Notes
Any extra information for reviewers.
Summary by CodeRabbit
Performance Improvements
Bug Fixes