nx: Error reading nxdeps.json
Current Behavior
While running some commands in parallel we receive the following error:
Error reading '/home/circleci/project/repo/node_modules/.cache/nx/nxdeps.json'. Continue the process without the cache.
Error: ValueExpected in /home/circleci/project/repo/node_modules/.cache/nx/nxdeps.json at position 0
at parseJson (/home/circleci/project/repo/node_modules/@nrwl/tao/src/utils/json.js:30:15)
at readJsonFile (/home/circleci/project/repo/node_modules/@nrwl/tao/src/utils/fileutils.js:21:37)
at readCache (/home/circleci/project/repo/node_modules/@nrwl/workspace/src/core/nx-deps/nx-deps-cache.js:41:46)
at Object.readCachedProjectGraph (/home/circleci/project/repo/node_modules/@nrwl/workspace/src/core/project-graph/project-graph.js:19:61)
at jestExecutor2 (/home/circleci/project/repo/node_modules/@*******org/nx-jest/src/executors/jest/jest.impl.js:107:46)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
[readCachedProjectGraph] ERROR: No cached ProjectGraph is available.
If you are leveraging \`readCachedProjectGraph()\` directly then you will need to refactor your usage to first ensure that
the ProjectGraph is created by calling \`await createProjectGraphAsync()\` somewhere before attempting to read the data.
(Note: we are using a jest executor that wraps the Nrwl Nx Jest executor to modify the jest config, doesn’t do anything with Nx itself, can find the code here, https://github.com/trellisorg/platform/tree/master/packages/nx-jest, it shouldn’t have anything to do with it.)
We have 3 e2e test suites (that actually just use jest) for our API, each of them has a dependsOn target:
"dependsOn": [
{ "target": "build", "projects": "dependencies" }
]
So that all dependencies of these e2e test suites (which are just node projects in the apps folder) are built (or pulled from cache) prior to running the e2e tests.
Then we run
yarn nx affected --target feature-e2e
and receive the error (not every time though)
Expected Behavior
Should not error and running commands in parallel should work fine.
Steps to Reproduce
This issue may not be prioritized if details are not provided to help us reproduce the issue.
Failure Logs
Error reading '/home/circleci/project/repo/node_modules/.cache/nx/nxdeps.json'. Continue the process without the cache.
Error: ValueExpected in /home/circleci/project/repo/node_modules/.cache/nx/nxdeps.json at position 0
at parseJson (/home/circleci/project/repo/node_modules/@nrwl/tao/src/utils/json.js:30:15)
at readJsonFile (/home/circleci/project/repo/node_modules/@nrwl/tao/src/utils/fileutils.js:21:37)
at readCache (/home/circleci/project/repo/node_modules/@nrwl/workspace/src/core/nx-deps/nx-deps-cache.js:41:46)
at Object.readCachedProjectGraph (/home/circleci/project/repo/node_modules/@nrwl/workspace/src/core/project-graph/project-graph.js:19:61)
at jestExecutor2 (/home/circleci/project/repo/node_modules/@*******org/nx-jest/src/executors/jest/jest.impl.js:107:46)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
[readCachedProjectGraph] ERROR: No cached ProjectGraph is available.
If you are leveraging \`readCachedProjectGraph()\` directly then you will need to refactor your usage to first ensure that
the ProjectGraph is created by calling \`await createProjectGraphAsync()\` somewhere before attempting to read the data
Environment
> NX Report complete - copy this into the issue template
Node : 12.22.7
OS : darwin x64
yarn : 1.22.17
nx : 13.8.3
@nrwl/angular : 13.8.3
@nrwl/cli : 13.8.3
@nrwl/cypress : 13.8.3
@nrwl/detox : undefined
@nrwl/devkit : 13.8.3
@nrwl/eslint-plugin-nx : 13.8.3
@nrwl/express : 13.8.3
@nrwl/jest : 13.8.3
@nrwl/js : 13.8.3
@nrwl/linter : 13.8.3
@nrwl/nest : 13.8.3
@nrwl/next : undefined
@nrwl/node : 13.8.3
@nrwl/nx-cloud : 13.1.5
@nrwl/react : undefined
@nrwl/react-native : undefined
@nrwl/schematics : undefined
@nrwl/storybook : 13.8.3
@nrwl/tao : 13.8.3
@nrwl/web : 13.8.3
@nrwl/workspace : 13.8.3
typescript : 4.5.5
rxjs : 7.4.0
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 35
- Comments: 18 (9 by maintainers)
Commits related to this issue
- fix(core): atomic writes of nxdeps.json When writing nxdeps.json prevent parallel processes from seing half-written files and prevent half written files to be left in case of process crash tob The i... — committed to jonhamm/nx by jonhamm 2 years ago
- fix(core): atomic writes of nxdeps.json When writing nxdeps.json prevent parallel processes from seing half-written files and prevent half written files to be left in case of process crash tob The i... — committed to jonhamm/nx by jonhamm 2 years ago
- fix(core): atomic writes of nxdeps.json When writing nxdeps.json prevent parallel processes from seing half-written files and prevent half written files to be left in case of process crash tob The i... — committed to jonhamm/nx by jonhamm 2 years ago
- fix(core): atomic writes of nxdeps.json When writing nxdeps.json prevent parallel processes from seing half-written files and prevent half written files to be left in case of process crash tob The i... — committed to jonhamm/nx by jonhamm 2 years ago
I noticed that the
writeCache()is getting called over and over again just writing the same data that is already there every time the graph is read. Adding a simple check to see if the data it is writing is already what is there should reduce the chances that it is in the middle of writing when reading starts.Can someone on the NX team weigh in on this (e.g. what solution would you merge if someone worked on it)?
The problem is still exits in version
14.4.3One workaround would be to disable the dependency graph cache completely by setting the
NX_CACHE_PROJECT_GRAPHenvironment variable tofalse.That being said, this looks like a deeper problem with concurrent runs while using a shared cache directory. If the NX team doesn’t assure other concurrent problems can’t happen in the future, it will never be safe for us developers to expect concurrent runs to work in future versions.
Bump, we currently migrating our Angular application to NX libraries on version 13.9.6. We have 1000+ modules and at this moment we migrated 100 of them and we had the same problem. It is a blocker for our firm because a lot of developers have this problem now. We found only one workaround, build every failed library separately
Also observing this. It’s likely caused by concurrent reads/writes to
nxdeps.json(whileat position 0seems to indicate that the file is always empty, we’ve sometimes observed it being non-zero, which is consistent with the process reading the file in the middle of a write operation executed by another process).Logging changes to
nxdeps.jsonduring certain nx commands with https://github.com/inotify-tools/inotify-tools shows the following:If this is indeed the root cause possible solutions include:
And now I have seen this issue multiple times too on a Jenkins build node where we run only one branch build at any point in time, so I totally agree that
NX_PROJECT_GRAPH_CACHE_DIRECTORYwill not solve the problem. It is quite frustrating that this is not solved yetWe still have it with v14.7.6 on our CI pipeline, even with
NX_DAEMONset tofalse.I haven’t tried the
NX_PROJECT_GRAPH_CACHE_DIRECTORYoption, as I don’t really understand how it could help for this issue, since it saves by default thenxdeps.jsonfile under thenode_modules. Our CI pipeline runs nx commands simultaneously (in parallel) within the same repo, other repos have their ownnode_modulesfolder. Setting it to another folder within the workspace will still result in the same issue I think?As workaround we read out this error message and run it again. Bit hacky, but it works…
Any update on this? For us this is a critical issue, I’m a bit surprised to see this still open after about half a year…
The problem is still exits in version 14.5.1
On our end at least, we are running into the issue on a single NX driven monorepository in a CI environment that is not sharing volumes with other build agents. We use yarn3, and node modules are hoisted to root of repo. So there is only a single
node_modules/.cache/nx/nxdeps.jsonfile. As @wimme states, I don’t see howNX_PROJECT_GRAPH_CACHE_DIRECTORYcould solve this.Initially setting
NX_CACHE_PROJECT_GRAPHjust made the error happen on any nx command in the CI instead of just on concurrent calls.So I instead set
NX_DAEMONto false and that greatly helped (fixed it on all my primary code quality test) I wonder why this wasn’t being caught already, the code seems to disable the domain for CI task already. I did run into issues when using https://www.npmjs.com/package/ngx-deploy-npm where it still gave the error.