Jest fails all the time due to "Failed to cache transform results" on Windows

[hon2a]

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

Most of my calls to jest.runCLI (I run jest from a gulpfile) end up with the following error:

jest: failed to cache transform results at ...

for random files. The stack shows a crashed fs.openSync at the top. This is happening to me on Windows 7 Enterprise (64-bit) and not to my colleagues using MacOS. Sometimes it happens once, sometimes it's many consecutive runs. I checked that it's not caused by too long file paths (it's pretty close though).

Funny thing is, this happens even when I run jest --no-cache directly from the command-line.

What is the expected behavior?

If there's a problem with caching, Jest should maybe warn about it, but recover and complete the test without the cache.

The current behavior means I have to remove jest from the dev build, so that I can build reliably, which sucks.

Please provide your exact Jest configuration and mention your Jest, node, yarn/npm version and operating system.

OS: Windows 7 Enterprise 64-bit (SP1)
Node: 7.4.0
Npm: 4.0.5
Jest: 19.0.2

[thymikee]

Does it happen on Jest v20?

[hon2a]

When I update Jest to 20.0.3, it crashes with

TypeError: Path must be a string. Received [ 'C:\\...' ]

(the path inside the Array points to the current directory). I guess I'd have to try updating Node as well, but I don't have time for that today. I'll try later.

[thymikee]

Reinstall node_modules and it should be fine

[hon2a]

I haven't had time to upgrade Node and test with the new Jest, but after the quite long time of the problem happening often, now suddenly it doesn't anymore. So I'll close for now and reopen with more details if it starts happening again.

[mborecki]

Hello.
Short note.

For me problems with "Failed to cache transform results" stops when I added --runInBand flag. (Win7)

[hon2a]

@mborecki Thanks for the hint. I'll try that if/when the issue crops up again.

[vzaidman]

--runInBand works for me but i dont want to run in band...

windows 10
node 8.4.0
npm 5.3.0
jest 21.0.2
babel-jest 21.0.2

[HipsterZipster]

This is happening to me as well on Windows 7 with jest@21.1.0, --runInBand resolves it but that makes it run significantly slower. There should be an actual solution to this.

i'll create a new ticket

[PinkyJie]

I think we need to reopen this issue, I can still see the same error. --runInBand will resolve it but it is really too slow.

[cristian-eriomenco]

Same issue here:
package.json

    "jest-cli": "^21.2.1",
    "my-module: "^1.5.0" // this one is npm link

.jest.json

{
    ...
    "transformIgnorePatterns": [
        "<rootDir>/node_modules/(?!my-module)"
    ],
   ...

Works only with --runInBand

[hon2a]

I've come across this with the new Jest again as well (21.2.1). It looks like the parallelization is causing access errors on Windows.

@HipsterZipster: If you're creating a new issue, thanks. I'm hesitant to reopen this as I have no clear small reproducible scenario.

[SimenB]

Does it happen with jest@test?

[hon2a]

Does it happen with jest@test?

@SimenB: What do you mean by that, please?

[SimenB]

if you do npm install --save-dev jest@test or yarn add --dev jest@test (which installs a beta version of jest), does the problem still occur?

[hon2a]

Ah :) With jest@test (v21.3.0-beta.8) I can no longer reproduce the issue. Please bear in mind that the reproduction is problematic as the issue seemed non-deterministic. That said, on a package where the problem seemed to be happening almost every time, the new version works well.

[hon2a]

@SimenB: ... and I've just had the issue happen even with jest@test.

[SimenB]

Have you tried applying the fix here: isaacs/node-graceful-fs#119?

[hon2a]

I'll try when I have a bit of time on my hands.

[goodbomb]

We're experiencing this issue on Windows Server 2016 with our TeamCity builds. Jest @ ~21.2.1

[goodbomb]

@HipsterZipster Do you have a link to that new ticket you created so that we can follow it?

[HipsterZipster]

@goodbomb I did not create a new ticket since I can't put together a reproducible scenario. My suspicion is that the security software on my corporate machine is aggravating it. Using --runInBand for now, but trying to dig deeper....

[christianchown]

Adding this here in case anyone else experiences it. I was getting the "Failed to cache transform results" error, and, finding this thread, overcame it using jest@test (21.3.0-beta.8).

However, having reinstalled node_modules, for jest@21.3.0-beta.9 - jest@21.3.0-beta.11 I get a node.exe error: "src\node_file.cc:835: Assertion '(args.Length()) >= (2)' failed".

I am explicitly using npm i -D jest@21.3.0-beta.8, which runs without issue.

Windows 10 x64
Node: 9.2.0
NPM: 5.5.1

[SimenB]

Interesting! Do you get that when running tests or installing?

[christianchown]

Running tests.

Let me know if there's anything I can provide debug-wise

[goodbomb]

I can confirm that jest@21.3.0-beta.8 continues to have this problem. I'm still getting jest: failed to cache transform results in: errors.

[goodbomb]

As a note, I was using v6.9.11 of node and an earlier version of npm 3.x.x I think. I decided to update node to v8.9.1 and npm to v5.5.1 and the issue seems to have been resolved in jest@21.3.0-beta.8.

[JoshuaKGoldberg]

Likely dup of #4444

[goodbomb]

I can confirm that this issue is still occurring with v8.9.1 of Node and v5.5.1 of npm. We're still getting this error with TeamCity builds.

[janacm]

Getting this issue on node v8.9.4 and npm v5.6.0 in typescript. Got it to work by running jest with -i switch.

[skhan75]

Have you mocked 'fs' ? This happened to me when I was trying to mock fs.mkdirSync.

[jednano]

Same issue here. Fixed it by updating all Jest dependencies to latest versions:

- "babel-jest": "23.0.0",
- "eslint-plugin-jest": "21.15.2",
- "jest": "23.0.0",
- "jest-cli": "23.0.0",
+ "babel-jest": "23.4.0",
+ "eslint-plugin-jest": "21.17.0",
+ "jest": "23.4.1",
+ "jest-cli": "23.4.1",

[mattsteve]

I'm running into this issue on Windows 7 with Jest 24.0.0.

[fluffynuts]

This is still an issue. I have my jest version set to "x" (meaning: always latest and greatest), my CI server does a git clean -fdx and npm install before build (and there is no package-lock.json in the project) and I still see stuff like this:

  jest: failed to read cache file: D:/phoenix/src/.jest-cache/jest-transform-cache-f691fb298581eda406946da746f68cf3-791c88db313af6e97cd5a90a918831b1/e6/order_e6d4e287214676f983806bccb2f628dc
    Failure message: ENOENT: no such file or directory, open 'D:/phoenix/src/.jest-cache/jest-transform-cache-f691fb298581eda406946da746f68cf3-791c88db313af6e97cd5a90a918831b1/e6/order_e6d4e287214676f983806bccb2f628dc'
      at readCacheFile (node_modules/jest-runtime/build/script_transformer.js:563:60)

(cache file went away?)

or this:

FAIL tests/components/tracking/tracking.vue.spec.ts
  â—� Test suite failed to run
    jest: failed to read cache file: D:/phoenix/src/.jest-cache/jest-transform-cache-f691fb298581eda406946da746f68cf3-791c88db313af6e97cd5a90a918831b1/f0/auto-completion-session_f0091c924a4ebc768da80b8fc8735194
    Failure message: EPERM: operation not permitted, open 'D:/phoenix/src/.jest-cache/jest-transform-cache-f691fb298581eda406946da746f68cf3-791c88db313af6e97cd5a90a918831b1/f0/auto-completion-session_f0091c924a4ebc768da80b8fc8735194'
      at readCacheFile (node_modules/jest-runtime/build/script_transformer.js:563:60)

(cache file still being generated?)

The caching mechanism needs to cater for this and other issues -- if it can't read the file it expects to, simply regenerate it with a new id. Which is worse: a small slowdown because a race condition made a cache file go away, or an entire build failing sporadically because of cache misses?

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.