Jest failing with "Call retries were exceeded", using --runInBand works-around issue

[martijnthe]

🐛 Bug Report

I've got 2 test files. In the test, a WebAssembly object gets instantiated. This instantiation seems to stall for some reason when running the test in CI. Locally running jest passes the tests fine.

In CI they fail with this error:

  ● Test suite failed to run

    Call retries were exceeded

      at ChildProcessWorker.initialize (../node_modules/jest-worker/build/workers/ChildProcessWorker.js:193:21)

When -i is used however, they pass as well in CI.

Jest: 24.8.0 Node: 10.15.0 Local env: macOS, 10.14.6 (18G84)) CI env: CircleCI, Docker Linux 6a7bd3b63625 4.15.0-1035-aws #37-Ubuntu SMP Mon Mar 18 16:15:14 UTC 2019 x86_64 GNU/Linux

To Reproduce

I don't have a concise repro repo at this moment.

Expected behavior

I expect the tests to pass as well when not run in band.

Link to repl or repo (highly encouraged)

Don't have it at this moment.

Run npx envinfo --preset jest

Paste the results here:

CI:

npx: installed 1 in 1.719s

  System:
    OS: Linux 4.15 Debian GNU/Linux 9 (stretch) 9 (stretch)
    CPU: (36) x64 Intel(R) Xeon(R) Platinum 8124M CPU @ 3.00GHz
  Binaries:
    Node: 10.15.0 - ~/.nodenv/versions/10.15.0/bin/node
    Yarn: 1.17.3 - /usr/bin/yarn
    npm: 6.4.1 - ~/.nodenv/versions/10.15.0/bin/npm

Local:

Environment:
  OS:  macOS 10.14.6
  Node:  10.15.0
  Yarn:  1.17.3
  npm:  6.4.1
  Watchman:  Not Found
  Xcode:  Xcode 10.3 Build version 10G8
  Android Studio:  3.1 AI-173.4819257

[lh0x00]

do you use jest-worker? Please provide more information about your use of it if available. or say more about the file that runs your test.

[martijnthe]

do you use jest-worker?

Not that I’m aware of? I do see it as a dependency in my yarn.lock file. But I didn’t add any configuration in the jest.config.js for it.

I will try to create a minimal repro example when I find some time.

[lh0x00]

Ok, do you provide a reproduce code?

[martijnthe]

I will try to create a minimal repro example when I find some time.

[fernandoabolafio]

Any lucky on this? I am having the same issue after upgrading to node v13.

[creativecomposer]

I observed that the issue occurs with node v13.2.0, but not with v13.1.0. Looks like the issue with only the latest node version.

[fernandoabolafio]

@antony2025 same here. After upgrading to node v13.2.0 my test suite which has many async test statements started to fail. Funny thing is that if I delete a few async tests from the test suite it works again.

[degouville]

Same for me I have the same issue w/ Node 10.17.0

[nelsieborja]

I just faced the same issue in CI and was able to reproduce it in local by switching to the latest version of node. As suggested, only by downgrading fixes it for me, using -i didn't.

[davidje13]

I have observed the same issue on Node 13.2.0 (where updating node is the only change since it was previously working reliably; package-lock.json has not changed, and I have tried before and after clearing out and rebuilding node_modules).

For me, running with --runInBand results in 8266 Segmentation fault: 11 at the same point where it otherwise fails with Call retries were exceeded at ChildProcessWorker.initialize. I am running on macOS 10.14.6 and installed node via Homebrew. After the crash it notes that it reached 33 passing test suites with 106 total tests. The codebase contains 34 test suites and 122 total tests (I don't know if these numbers are similar for other people hitting the issue?). I have many async tests in the rest of the code but the suite which hits this error contains only synchronous tests.

Since it's segfaulting, I suspect this is a bug in Node itself (seemingly a regression since this was an issue before), but I have no idea where to begin looking!

---

Is it possible that this could be connected to https://github.com/nodejs/node/pull/26628 ? (seems to be the only entry in the Node 13.2.0 changelog which relates to workers)

[davidje13]

Appears this issue has been reported upstream: nodejs/node#30730

[rafaelcamargo]

Hey guys! I was having this issue on CI only (CircleCI). So I changed the following value on CI config file and the issue has gone:

Before

version: 2
jobs:
  build:
    docker:
      - image: circleci/node:latest-browsers

Then

version: 2
jobs:
  build:
    docker:
      - image: circleci/node:12-browsers

[JimiSweden]

(note: not sure if this is the exact same error reason, but looks like it and I found this link when looking for a solution)

Error:

Test suite failed to run Call retries were exceeded at ChildProcessWorker.initialize (node_modules/jest-worker/build/workers/ChildProcessWorker.js:193:21)

Confirmed fix:

Upgrade from nodejs 13.2.0 to 13.3.0

Environment

I had this error with Windows 10 nodejs 13.2.0 Yarn 1.19.2

Package.json

"dependencies": {
    "@testing-library/jest-dom": "^4.2.4",
    "@testing-library/react": "^9.3.2",
    "@testing-library/user-event": "^7.1.2",
    "react": "^16.12.0",
    "react-dom": "^16.12.0",
    "react-redux": "^7.1.3",
    "react-scripts": "3.3.0",
    "redux": "^4.0.4"
  },
"devDependencies": {
    "@storybook/addon-actions": "^5.3.0-beta.16",
    "@storybook/addon-docs": "^5.3.0-beta.16",
    "@storybook/addon-knobs": "^5.3.0-beta.16",
    "@storybook/addon-links": "^5.3.0-beta.16",
    "@storybook/addon-storyshots": "^5.3.0-beta.16",
    "@storybook/addons": "^5.3.0-beta.16",
    "@storybook/preset-create-react-app": "^1.3.2",
    "@storybook/react": "^5.3.0-beta.16",
    "babel-loader": "^8.0.6",
    "react-test-renderer": "^16.12.0"
  }

Storybook initStoryshots from '@storybook/addon-storyshots'

When following the tutorial in https://www.learnstorybook.com/intro-to-storybook/react/en/simple-component/

The code below is where the error occured.

// src/storybook.test.js
import initStoryshots from '@storybook/addon-storyshots';
initStoryshots();

[asarapas]

Believe got same issue on Node LTS 12.14.1:

ERROR in main.affbaa778346b006d3f5.js from Terser
Error: Call retries were exceeded
    at ChildProcessWorker.initialize (C:\azagent\A3\_work\1\s\Core\Web\NgApps\node_modules\jest-worker\build\workers\ChildProcessWorker.js:193:21)
    at ChildProcessWorker.onExit (C:\azagent\A3\_work\1\s\Core\Web\NgApps\node_modules\jest-worker\build\workers\ChildProcessWorker.js:263:12)
    at ChildProcess.emit (events.js:223:5)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:272:12)

[mvasin]

What helped me was upgrading the runner machine to the one with more memory.

[sibelius]

@mvasin how much memory has your machine now?

[gocarlos]

same with node 10.19.0, ubuntu 20.04

[carbonrobot]

Working version for our builds: 12.16.3 Broken when upgrading to 12.18.0

Running 16GB memory, 8cpu on circleCI with the following options

yarn --coverage --ci -w 6

[dimagimburg]

adding --runInBand, worked for me. I don't know why and I don't care as long as i see greens :green_circle: :see_no_evil:

[justinlazaro-iselect]

any solution on this?

[davidje13]

@justinlazaro-iselect you should probably check https://github.com/nodejs/node/issues/30730 since this is actually a NodeJS issue - I think the result is that this bug isn't fixed on Node 12 (yet? there seems to be talk about various dependencies on backporting things so it might be fixed eventually), but it is fixed in Node 13+

[justinlazaro-iselect]

@davidje13 thanks for the info, will check right now I'm update to node v13.3.0 still having and issue call still having an issue Call retries were exceeded any workaround to react-script test for this?

[amacneil]

I don't know if it helps anyone, but I was getting this error when running in a docker container on macOS, and I fixed it by increasing the memory available in Docker Desktop for Mac preferences.

[rahulballal]

It is a bit embarassing for us node devs that 2 cpu and 4gb ram cannot run unit tests properly :disappointed:

[amacneil]

Well don't feel quite so bad, the default was 2gb ram and increasing to 4gb prevented this error 🙂

[snoopdouglas]

Just spotted this in the docs:

For environments with variable CPUs available, you can use percentage based configuration: --maxWorkers=50%

We're going to use this for a while and see whether this issue still happens.

Update: we've done a few builds since and haven't noticed any failures, so this looks like a good option.

[csvan]

This now produces actual errors and fails the test suite on Nodejs 15, where unhandled promise errors are treated as exceptions.

[zombieJ]

This now produces actual errors and fails the test suite on Nodejs 15, where unhandled promise errors are treated as exceptions.

You save my time 👍

[carlpaten]

I'm seeing this on Node 10 as well!

[colepeters]

I'm also seeing this on Node 14, specifically 14.15.1. Running with --runInBand fails with a SIGSEGV.

[eXist-FraGGer]

Seeing this on 12.18.4/12.20.0/13.1.0

[bpossolo]

also seeing this on node 12.18.4 with jest 26.6.3 and angular 10.2.3.

when running as the whole test suite, i experience the same problem that the original author listed (call retries exceeded in the ChildProcessWorker.initialize() method). when running via npx jest .... some.spec.ts i get a seg fault

[rnike]

seeing this on node 14.15.0

[D4nt4lion]

Still an issue using 14.14.0+

[rs-afrize]

Still has an issue on NodeJS 15.5.1

[cellog]

I have tests that use a native node module (tree-sitter) that trigger this behavior. similarly, --runInBand triggers a segfault. --maxWorkers="50%" had no effect. node 14.15.4

[adeelibr]

Having the same issue, using workers

[cellog]

@lamhieu-vk Anyone can easily reproduce this bug locally. Here's how:

1. yarn add -D segfault-handler
2. write this test:

var SegfaultHandler = require('segfault-handler');

describe("segfault", () => {
  it("should segfault", () => {
    SegfaultHandler.causeSegfault();
  });
})

3. write at least 1 other test
4. yarn jest (or whatever your test command is)

Output:

 PASS  src/utils/mergeIndexDTs.test.js
 PASS  src/utils/getIndexEntries.test.js
 PASS  src/drivers/translationDriverTests.test.js
NodeSegfaultHandlerNative: about to dereference NULL (will cause a SIGSEGV)
NodeSegfaultHandlerNative: about to dereference NULL (will cause a SIGSEGV)
NodeSegfaultHandlerNative: about to dereference NULL (will cause a SIGSEGV)
 FAIL  src/drivers/segfault.test.js
  ● Test suite failed to run

    Call retries were exceeded

      at ChildProcessWorker.initialize (../../node_modules/jest-worker/build/workers/ChildProcessWorker.js:193:21)

Test Suites: 1 failed, 10 passed, 11 total
Tests:       60 passed, 60 total
Snapshots:   36 passed, 36 total
Time:        8.243 s

The bug in jest is that it does NOT display "your test caused a segfault in node."

This is a combination of 2 bugs. The more serious one is SOMETHING IN YOUR TEST CAUSES A SEGFAULT :). But Jest should still tell us that the process segfaulted.

Fortunately, I can tell you that ChildProcess does report the SIGSEGV in its internals because I stepped through a jest test with the chrome debugger to make sure, so it's just a question of Jest noticing this in ChildProcessWorker.initialize() when retrying, and reporting "the test caused a segmentation fault in node, likely due to a serious bug in an internal module you are using." or some such language

[gomesbreno]

[SOLVED]

just use: jest.useFakeTimers()

[danielsanfr]

Running the tests at CircleCI, I found that if I just run jest, the error that normally appears is: "Call retries were exceeded".

But if I execute jest --coverage the first error that appears is "ENOMEM: not enough memory, read" and then the error above appears.

To solve the problem I am now using jest --maxWorkers=4 and jest --coverage --maxWorkers=4.

[alielkhateeb]

I'm facing this issue too, any update?

[smcaleese]

I updated my node version from 12.18 to 15.8 and that solved the problem for me.

[villesau]

This also seems to happen on our CI with 62G total memory of which 17G+ is free & 8 cores and only handful of tests. But I'm not able to repro this locally with smaller memory but more cores.

[villesau]

For us this actually happened due to uncaught promise rejection. The error message was pretty far from actionable :D So there is apparently far more reasons for this error to occur than just OOM.

[sirshurak]

"react": "^17.0.1" "enzyme": "^3.11.0" "jest-enzyme": "^7.1.2" "@wojtekmaj/enzyme-adapter-react-17": "^0.4.1"

With any node version, still happening

[FahmyChaabane]

Any updates on this one ? I am having the same issue. Ubuntu : 20:04 Node : 12.18.4

• I did upgrade Node to 14.15.5, still facing the same issue.

[villesau]

@FahmyChaabane if You know which file is causing the error, try wrapping the tests into try catch (in an async function) and, see what kind of errors you get and try to fix those. That might help.

[sirshurak]

I've added 2 flags to my react-scripts test and removed some Lazy loadings when it's on test stage

cross-env NODE_ENV=test react-scripts test --unhandled-rejections=warn --runInBand

And then in the code, im checking if it's in test stage env. Example:

  let ReactPlayer;
  if (global.__TEST__) ReactPlayer = require('react-player').default;
  else ReactPlayer = require('react-player/lazy').default;

My jest.setup.js

 global.__TEST__ = true;

Hope it helps someone.

[n1313]

In my case, this bug occurred only when a specific combination of props was passed to my component. I went through code commenting out different parts related to these props and found that if I remove (or mock out) my lazily loaded Dropzone sub-component then the problem goes away. To everyone experiencing this issue, try commenting out parts of your component to find your culprit.

[gbalatckii]

Maybe it helps someone, but for me the problem was, that I had process.env.NAME in the code and the same env variable was defined on my Mac, but not on the CI-Machine. This way all my tests were green, but on CI red.