-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
fix: use graceful-fs all over instead of monkey patching fs #9443
Conversation
f2a03ac
to
0d1b938
Compare
CI OOMs - that's a bad sign... |
d614c6f
to
f36fad7
Compare
Seems to leak when running in band, running in workers and heap size seems stable. I don't have time to dig into this now. Seems to happen on master as well, so not sure why it explodes on CI now and didn't before... |
Does it make sense to maybe consider merging this as a fix: #8331 |
d44b0d4
to
84bf591
Compare
Seems to fix the memory issues on CI, so |
I've opened a PR at graceful-fs that seemingly fixes this: isaacs/node-graceful-fs#184 |
84bf591
to
8dd5817
Compare
Codecov Report
@@ Coverage Diff @@
## master #9443 +/- ##
=======================================
Coverage 64.92% 64.92%
=======================================
Files 288 288
Lines 12199 12199
Branches 3024 3024
=======================================
Hits 7920 7920
+ Misses 3639 3638 -1
- Partials 640 641 +1
Continue to review full report at Codecov.
|
@@ -24,10 +24,6 @@ export async function run( | |||
cliArgv?: Config.Argv, | |||
cliInfo?: Array<string>, | |||
): Promise<void> { | |||
const realFs = require('fs'); | |||
const fs = require('graceful-fs'); | |||
fs.gracefulify(realFs); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is the fix, buried in fs -> graceful-fs
import changes
Data point: this solution makes the leak worse in our repo. |
@ron23 did you include the patch for graceful-fs? It's the last commit. The patch is the fix for the memory leaks, the changes in this PR without the patch is expected to make things worse since we load a new (leaking) graceful-fs each time (similar to what happens when people load graceful-fs in their tests). |
Oops I have not, didn't realize I need to. EDIT: my leak might be coming from different place as well, so don't take that as if your PR ain't working. If only I knew where the leak is coming from... |
For testing I recommend not to link anything (there's so many packages and inter-dependencies it's easy to miss some). This is easier:
|
64ac79a
to
d8cd798
Compare
8293c0c
to
37413b1
Compare
37413b1
to
88e41c3
Compare
Upstream PR has been merged, just need to wait for a release and we can merge this |
19ae6d6
to
a2a7802
Compare
This reverts commit d19bdb5.
Couple of things here: **require.cache** In version `v25.5.0`, jest introduced an [implementation](jestjs/jest#9841) of their own to the `require.cache` object. It seems that it doesn't handle caching `json` modules properly, which causes our code to fail because `mod.paths` is `undefined` when we are querying for `json` files that were required (for example `package.json` or `cloud-assembly.schema.json`). https://github.com/aws/aws-cdk/blob/07fe642e38118e24837b492fa182737fc41bb429/packages/%40aws-cdk/core/lib/private/runtime-info.ts#L66 ```console TypeError: Cannot read property 'map' of undefined ``` The "fix" was to add a null check to prevent failure when looking up modules who don't have the `paths` property defined. Note that this was only observed in test environments using `jest > v25.5.0`, not during actual runtime of `cdk synth`. This is because `jest` manipulates the built-in `require` module of `nodejs`. **graceful-fs** In version `v25.5.0`, jest [added](jestjs/jest#9443) a dependency on the `graceful-fs` package. The version they depend on (`4.2.4`) differs from the version that we bring (`4.2.3`). This caused the `graceful-fs` dependency that comes from `jest` no to be deduped by node at installation. In turn, this caused multiple copies of the library to be installed on disk. The `graceful-fs` package monkey patches the `process.chdir` and `process.cwd` functions with a cached version for better performance. For reasons not completely clear to us, the existence of multiple copies of the module, caused `process.cwd()` to return incorrect cached results, essentially always returning the directory that the process was started from, without consideration to calls to `process.chdir`. This broke `decdk` (and possibly many more) tests which rely on `process.chdir`. Fixes #7657
Couple of things here: **require.cache** In version `v25.5.0`, jest introduced an [implementation](jestjs/jest#9841) of their own to the `require.cache` object. It seems that it doesn't handle caching `json` modules properly, which causes our code to fail because `mod.paths` is `undefined` when we are querying for `json` files that were required (for example `package.json` or `cloud-assembly.schema.json`). https://github.com/aws/aws-cdk/blob/07fe642e38118e24837b492fa182737fc41bb429/packages/%40aws-cdk/core/lib/private/runtime-info.ts#L66 ```console TypeError: Cannot read property 'map' of undefined ``` The "fix" was to add a null check to prevent failure when looking up modules who don't have the `paths` property defined. Note that this was only observed in test environments using `jest > v25.5.0`, not during actual runtime of `cdk synth`. This is because `jest` manipulates the built-in `require` module of `nodejs`. **graceful-fs** In version `v25.5.0`, jest [added](jestjs/jest#9443) a dependency on the `graceful-fs` package. The version they depend on (`4.2.4`) differs from the version that we bring (`4.2.3`). This caused the `graceful-fs` dependency that comes from `jest` no to be deduped by node at installation. In turn, this caused multiple copies of the library to be installed on disk. The `graceful-fs` package monkey patches the `process.chdir` and `process.cwd` functions with a cached version for better performance. For reasons not completely clear to us, the existence of multiple copies of the module, caused `process.cwd()` to return incorrect cached results, essentially always returning the directory that the process was started from, without consideration to calls to `process.chdir`. This broke `decdk` (and possibly many more) tests which rely on `process.chdir`. Fixes #7657
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Summary
From
graceful-fs
's readme:This might cause errors if some dependency we use do a lot of fs operations, but if so we should send them a PR using
graceful-fs
themselves. And users hitting it can choose to manuallygracefulify
themselves if they want to.Ref #8331.
Test plan
Green CI.