feat(core): batch hash tasks without custom hashers #33327
Conversation
Currently when processing scheduled batches, tasks are hashed one at a time even though the hasher has a hashTasks method for batch hashing. This change introduces a new hashTasks function that: - Filters out tasks that already have a hash - Separates tasks with custom hashers from those without - Uses Promise.all to hash tasks with custom hashers individually - Uses the hasher's hashTasks method to batch-hash tasks without custom hashers for better performance The processScheduledBatch method in task-orchestrator now uses this new function instead of mapping over individual hashTask calls.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
✅ Deploy Preview for nx-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
View your CI Pipeline Execution ↗ for commit c2bb073
☁️ Nx Cloud last updated this comment at |
![nx-cloud[bot]](https://cdn.statically.io/img/avatars.githubusercontent.com/in/80458?s=60&v=4){kind=small}
There was a problem hiding this comment.
Nx Cloud has identified a possible root cause for your failed CI:
The failure is classified as 'environment_state' rather than 'code_change' for the following reasons:
-
No Correlation Between Code Changes and Failure
The PR modifies task hashing logic inhash-task.tsandtask-orchestrator.ts, specifically optimizing how tasks are hashed by batching tasks without custom hashers. The failure occurs due to port 41404 already being in use (EADDRINUSE), which has no logical connection to task hashing optimizations. -
Resource Constraint Error
The error "Error: listen EADDRINUSE: address already in use :::41404" is a classic environmental resource constraint. This indicates that the port was not properly released from a previous test run or process, which is an infrastructure/cleanup issue, not a code logic issue. -
No References to Changed Code
The error output contains no references tohashTask,hashTasks,processScheduledBatch, or any other functions modified in the PR. The failure occurs entirely within the dev server startup phase of the E2E test infrastructure. -
Test Pattern Suggests Timing Issue
The first test case with--js=falsepassed successfully (158207 ms), while the second test case with--js=truefailed (154630 ms). This pattern is characteristic of timing or race conditions in test cleanup, not deterministic code failures. -
Failure in Test Infrastructure, Not Application Code
The failure occurs during dev server initialization for module federation remotes, which is part of the E2E test infrastructure. The changed code affects task hashing during build/execution orchestration, which happens before the dev servers are even started. -
Environmental Indicators Present
Multiple environmental indicators are present: ECONNREFUSED errors, EADDRINUSE error, and the web server timeout after 60000ms. These are all symptoms of environmental issues rather than code defects.
The PR's changes optimize task hashing performance and do not modify port allocation, dev server management, test cleanup logic, or any infrastructure code that would cause port conflicts.
A code change would likely not resolve this issue, so no action was taken.
🎓 To learn more about Self Healing CI, please visit nx.dev
Current Behavior
When processing scheduled batches, tasks are hashed one at a time even though the hasher has a
hashTasksmethod for batch hashing.Results from a batch with 109 tasks.
Expected Behavior
Tasks without custom hashers should be batch-hashed using the hasher's
hashTasksmethod for better performance.Results from a batch with 109 tasks.
Related Issue(s)
This is a performance optimization for task hashing.
Changes:
hashTasksfunction that intelligently separates tasks with custom hashers from those withoutPromise.allhashTasksmethodprocessScheduledBatchin task-orchestrator to use this new function