[rush-lib] Fix weighted concurrency budget being capped by operation count#5646
Open
itsnothuy wants to merge 2 commits intomicrosoft:mainfrom
Open
[rush-lib] Fix weighted concurrency budget being capped by operation count#5646itsnothuy wants to merge 2 commits intomicrosoft:mainfrom
itsnothuy wants to merge 2 commits intomicrosoft:mainfrom
Conversation
…count test(rush-lib): expand weighted concurrency edge case tests test(rush-lib): expand weighted concurrency edge case tests refactor(OperationExecutionManager.test): align comment and naming style with codebase conventions - Replace // ─── section banners and // Test N: numbered headers with brief inline prose comments matching the existing test file style - Replace // WHAT: / // SCENARIO: / // DETERMINISM: structured blocks with concise inline comments - Rename createWeightedOp → createWeightedOperation for consistency with other helper names (createExecutionManager, etc.) - Rename counters.active / counters.peak → counters.concurrentCount / counters.peakConcurrency for self-documenting field names - Extract new AbortController() calls into named abortController variables matching the pattern used throughout the rest of the test file - No logic or assertion changes; all 18 tests continue to pass chore: add rush change file for @microsoft/rush-lib weighted concurrency fix refactor: reduce test comment density to match codebase patterns
itsnothuy
requested review from
apostolisms,
bmiddha,
dmichon-msft,
iclanton,
jxanthony and
octogonz
as code owners
There was a problem hiding this comment.
Pull request overview
Fixes a weighted scheduling bug in rush-lib where the concurrency unit budget was being incorrectly reduced to the number of operations, preventing expected parallelism when Operation.weight > 1.
Changes:
- Pass the full
parallelismvalue as the weighted scheduler’s concurrency unit budget (no longer capped by operation count). - Improve the startup log message to cap the displayed “simultaneous processes” count by the number of operations (UX clarity).
- Add a comprehensive Jest test suite covering weighted concurrency behaviors (regression, clamping, oversubscription, mixed/zero weights, and display output).
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| libraries/rush-lib/src/logic/operations/OperationExecutionManager.ts | Fixes the weighted scheduler’s concurrency budget and separates display calculation from scheduling. |
| libraries/rush-lib/src/logic/operations/test/OperationExecutionManager.test.ts | Adds deterministic test coverage for weighted concurrency scenarios and logging output. |
| common/changes/@microsoft/rush-lib/fix_weighted-concurrency-cap_2026-02-19-07-57.json | Patch change file documenting the fix for release notes/versioning. |
Author
@microsoft-github-policy-service agree |
Member
|
@dmichon-msft - mind reviewing this? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #5607 — resolves a weighted scheduling bug where the concurrency unit budget was incorrectly capped by the number of operations.
Background
When Rush uses weighted scheduling (
Operation.weight> 1), theconcurrencyparameter inAsync.forEachAsyncrepresents a unit budget, not a task count. However,OperationExecutionManagerwas passingMath.min(totalOperations, parallelism), which shrinks the budget whentotalOperations < parallelism.Example: 4 operations with weight=4, parallelism=10:
concurrency = min(4, 10) = 4→ only 1 operation fits → sequential executionconcurrency = 10→ 2 operations fit (4+4=8 ≤ 10) → parallel executionThis was reported by @LPegasus in issue #5607.
Changes
1. Fix:
OperationExecutionManager.tsMath.min(totalOperations, parallelism)to avoid confusing messages like "max 10 processes" when only 4 operations exist (a UX improvement over the old code which showed rawthis._parallelism)this._parallelismdirectly as the full unit budget (the core fix)2. Tests:
OperationExecutionManager.test.tsAdded 9 new tests in a "Weighted concurrency" describe block:
All tests are deterministic (no timing dependencies) and use
Async.sleepAsync(0)to yield control to the scheduler.Impact
Testing
rush build --to rush-libsucceedsScope
This PR addresses only the scheduling bug. The
"weight": "NN%"feature (Proposal 1 in #5607) is intentionally excluded — it requires schema changes and maintainer design approval, so it should be a separate PR.Checklist
rush build --to rush-liblocally (passes)rush changeand committed change file