-
Notifications
You must be signed in to change notification settings - Fork 2.6k
fix(core): add synchronous file lock support for readCachedProjectGraph #32193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
When multiple processes call readCachedProjectGraph() simultaneously before the cache exists, they would all fail with "No cached ProjectGraph is available" error. This was common when running parallel builds. The fix adds synchronous waiting when a lock file exists, indicating another process is building the graph. Uses Atomics.wait() for efficient blocking without CPU usage. - Wait up to 120 seconds for graph to be built - Check every 200ms for graph availability - Detect if other process fails (lock removed, no graph) - Provide helpful timeout message with lock cleanup instructions Fixes nrwl#31648 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
…-race-condition-v2
…OOO/nx into fix/project-graph-race-condition-v2
…graph" This reverts commit 45cd667.
- Add waitSync() method to native FileLock class for synchronous blocking - Fix race condition where readCachedProjectGraph fails when another process is building - Properly wait for OS-level file locks instead of checking file existence Addresses nrwl#31648
Add synchronous lock acquisition to prevent race conditions when multiple processes attempt to read the cached project graph simultaneously. The sync method uses blocking I/O to ensure exclusive access during graph deserialization. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
…-race-condition-v3
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
View your CI Pipeline Execution ↗ for commit 2056d5f
☁️ Nx Cloud last updated this comment at |
Could we have a review here @AgentEnder @leosvelperez -- this made all my crashes go away and i've stably used it for a week. |
Would love this to be looked at, majority of my team are having issues with this on 21.3.5. |
JFYI this fix still works solidly on our project. @AgentEnder @leosvelperez |
@moinerus can you confirm that this still happens on 21.3.11 (latest release)? |
Same problem here. We need to do "rm -rf .angular && rm -rf .nx && rm -rf dist && rm -rf tmp" almost before every build |
Ok we did the minor bump to 12.3.11 and it looks like the issue is resolved. |
Current Behavior
When multiple Nx processes attempt to read the cached project graph simultaneously, a race
condition can occur that results in the error "[readCachedProjectGraph]: No cached ProjectGraph is available". This
happens because:
The current implementation lacks proper synchronization between processes during graph
building and reading operations.
While hard to reproduce, this has been encountered by multiple users: #31648
Expected Behavior
With this PR, processes now wait for graph building to complete instead of failing immediately:
immediately)
The key change is adding synchronous waiting behavior to the existing OS-level file locking. Processes that
previously failed with "No cached ProjectGraph is available" now wait for the graph to be ready, eliminating
the race condition.
Related Issue(s)
Fixes #31648
Implementation Details
This PR is a second attempt after #32162 was rejected based on feedback by @AgentEnder.
This PR's approach properly uses OS-level read/write locks rather than checking for lock file existence.
The fix has been validated in production environments where the race condition was
reproducible, and the error no longer occurs with these changes.