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

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

Issue Analytics

State:
Created 6 years ago
Reactions:16
Comments:34 (1 by maintainers)

Top GitHub Comments

15reactions

HipsterZipstercommented, Sep 18, 2017

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

10reactions

fluffynutscommented, May 21, 2020

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?