chore(repo): Increase number of concurrently running nx tasks#19443
chore(repo): Increase number of concurrently running nx tasks#19443
Conversation
size-limit report 📦
|
node-overhead report 🧳Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.
|
|
hmm somehow this surfaces various test failures. Wondering if this is a problem with some kind of interference when running stuff in parallel. I don't think we can merge this PR in this state but I'd be really curious what's actually causing these fails |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| "autoExit": true | ||
| } | ||
| }, | ||
| "parallel": 5 |
There was a problem hiding this comment.
Parallel value 5 contradicts PR-described value of 10
Low Severity
The PR description explicitly states "This PR sets the limit to 10" and the benchmarks compare "3 vs 10 tasks in parallel," but the actual committed value is "parallel": 5. The cited speed improvements (e.g., build:tarball 135s → 98s) were measured at parallel: 10, not 5, so the expected performance gains described in the PR won't be realized. Either the value or the description needs updating to avoid confusion during review.


After moving from lerna to nx, I noticed we run fewer tasks in parrallel. This PR sets the limit to
105. previously, we used the default value 3.If reviewers prefer a different number than
105, I'm happy to change it. On my local build this led to good results but mileage may vary.UPDATE: I reduced the number from 10 to 5 because 10 concurrent tasks produced random test fails. After a bit or research, this most likely relates to memory pressure or CPU starvation, due to many parallel running threads. Vitest and Playwright run tests in multiple threads, so if we multiply this with more concurrently running tests, this produceds a lot of threads, especially in resource-constrained CI runners. We could experiment further with a higher threshold but for now I'd keep 5. If we run into inexplicable test fails, this is the PR we need to revert.
Closes #19444 (added automatically)