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

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

adding --runInBand, worked for me. I don’t know why and I don’t care as long as i see greens 🟢 🙈

Meet the same issue when upgrade node from 12.13 to 16, any update on this? “jest”: “^25.5.4”, “react”: “^16.14.0”, “node”: “16”

Test suite failed to run

    Call retries were exceeded

      at ChildProcessWorker.initialize (node_modules/jest-worker/build/workers/ChildProcessWorker.js:191:21)
      at ChildProcess.emit (node:events:394:28)
      at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12)

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)

I’ve run into this issue when updating a codebase from Node12 -> Node16 and in my digging I’ve found that in the bits that are now failing all seem to have the following in common when I run with a debugger attached.

[DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Which would indicate to me that the behaviour it was relying on, unhandled promise rejections continue, now cause a termination in Node, which Jest is detecting, running the test an additional 3 times before declaring it as dead and marks it as a test suite that has failed to execute.

What is interesting is that in Node12 those tests pass even when unhandled promise rejection is being fired as long as it’s not actually impacting any of the bits that are being tested.

Would it be possible to bubble up those Unhandled promise rejection errors so it’s easier for people to spot rather than having to spelunk using the debugger to work out what is wrong?

Jest 27.2.3 Node 12.18.2 - All tests work as expected Node 16.13.0 - Tests that contain an Unhandled promise rejection fail, even if it’s not in the tests critical path

Same Problem here:

 FAIL  __tests__/homepage.test.tsx
  ● Test suite failed to run

    Jest worker encountered 4 child process exceptions, exceeding retry limit

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

Node version: v16.13.0

Does anyone got a fix?

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.

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

This was the case for us, too. I suspect if anyone else out there is seeing test suites fail to run with the “Call retries were exceeded” message after upgrading to Node 15 and above, you might want to hunt down and fix any unhanded promise rejections in your codebase.

I created a small reproducing repo in case it helps anyone on the Jest team: https://github.com/scitech/call-retries-repro

I think the issue here is, Jest will spawn some number of workers which will each attempt to fork a process. If a worker’s process dies it forks another one, but after 3 tries it will stop running tests, and subsequent test suites will fail with the rather obscure error message “Call retries were exceeded”. So it’s not specifically related to unhandled promise rejections or memory issues (as in the OP) – the failure could be due to a worker encountering 3 Node exceptions of any kind.

Given that unhandled promise rejections are pretty common in application code, I wonder if there isn’t a more informative way to presenting this information to the Jest user so they can track down the issue. Forgive the unsolicited suggestions but here are some ideas:

1. Changing the error message text. “Call retries exceeded” is pretty opaque, maybe to something like “Jest worker process exited 3 times due to Node process exceptions, exceeding retry limit.”
2. If a child process worker exceeds the retry limit, can it bail early, rather than run all the tests marking each as failed? It’s harder to find the original source of the problem as is.
3. Can the exit handler of the ChildProcessWorker collect the Node process exception messages and report them back out after exceeding the retry limit?

We ran into this issue when upgrading from Node 14 to Node 16. It appears that Node 15 introduced a breaking change to promise rejection handling, as @jamesRaybould indicated earlier. I found https://developer.ibm.com/blogs/nodejs-15-release-blog/ to be a helpful writeup of the change.

We saw the errors disappear after passing the --unhandled-rejections=warn flag to node when running tests, which likely confirms this diagnosis.

Passing that flag may work as a short term workaround.

Still has an issue on NodeJS 15.5.1

[SOLVED]

just use: jest.useFakeTimers()

In my case we’re missing an await before wairFor from @testing-library/react

- waitFor(() => {

+ await waitFor(() => {
      expect(screen.getByTestId('my-button')).toBeInTheDocument();

If we run with node 16, it does not complain at all. Node 14 yells Call retries were exceeded without any implicit error message and it’s very difficult to spot the bug.

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

From my understanding of the problem I think the best fix for this is probably to fix the problem at source, in my case it’s a combination of us not mocking out dependencies properly and a couple of places where we don’t actually handle the promise rejection (at all). So fixing those will get us to a place where it all works as expected.

I’m not sure that there is a fix that can go in Jest other than to maybe better highlight where the unhandledPromiseRejection is being thrown.

I faced the same error when I was using node version 16.3. Changing the version from 16.3 to 12.6.3 resolved this issue.

Conclusion

If you are experiencing this issue on a CI environment, it’s probably caused by a CPU limit that prevents Jest from creating as many child processes as it wants.

Try setting --maxWorkers option to appropriate value to tell Jest how many child processes it can possibly request.

Original comment

I’m experiencing this issue on GitLab CI on a k8s cluster after I set the CPU limit of the runner pod to 5 cores (while the cluster has 40 in total).

I guess the Node.js told jest-runner that the system has 40 cores so jest-runner requested for according number of child processes, then the CPU limit caused the child process request to fail.

Solved with setting --maxWorkers to lower than 5.

@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();
  });
})

1. write at least 1 other test
2. 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

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

Guys for me it was just the node version that i use in localhost is not the the same used in the pipeline to run tests !

Seeing this on 12.18.4/12.20.0/13.1.0

@jiaoqiqi I’m also still seeing this issue on node 16.9. However, I’ve been able to mitigate this by pinning node to 16.8.

Hopefully there is a longer term fix soon.

I’m having this issue on 16.8.0 I have a feeling that the node version is a red herring and the problem is getting fixed after upgrades/downgrades because something else changes as a side effect.

Still an issue using 14.14.0+

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

jamesRaybould’s description matches the problem I have as well. Worked in node 14.17.16, fails in 16.13.0.

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

seeing this on node 14.15.0

Having the same problem

jest: 26.6.3 node: 15.5.1

node:internal/process/promises:227
          triggerUncaughtException(err, true /* fromPromise */);

Call retries were exceeded

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

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.

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

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

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

@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.

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.

I am seeing a similar issue with node v16.10.0. In my case, however, I am running locally and --runInBand causes the test to throw:

node:internal/process/promises:246
          triggerUncaughtException(err, true /* fromPromise */);
          ^

[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "Error: For security reasons, `window.crypto` is required to run `auth0-spa-js`.".] {
  code: 'ERR_UNHANDLED_REJECTION'
}

Reverting back to node 12.20.1 resolves the issue but it seems like more than just a node version problem.

I think I had the same error:

Failed to construct transformer: { Error: Call retries were exceeded at ChildProcessWorker.initialize (/Users/developer/Documents/dev/docomondo/app/node_modules/jest-worker/build/workers/ChildProcessWorker.js:193:21) at ChildProcessWorker._onExit (/Users/developer/Documents/dev/docomondo/app/node_modules/jest-worker/build/workers/ChildProcessWorker.js:274:12) at ChildProcess.emit (events.js:198:13) at Process.ChildProcess._handle.onexit (internal/child_process.js:248:12) type: ‘WorkerError’ }

I updated node from v10.19.0 to v14.17.0 and it works now

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

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

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.

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.

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

I was trying to run the craco tests and I got the error:

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

I added the option for Node.js for craco test command:

NODE_OPTIONS=--unhandled-rejections=warn craco test

My package.json:

"scripts": {
"test": "NODE_OPTIONS=--unhandled-rejections=warn craco test" }

全体起立！ 在 setupTests.js 或者出现问题的单元测试文件添加下面的代码，完美解决！！！

process.on('unhandledRejection', (reason) => {});

参考：https://2ality.com/2016/04/unhandled-rejections.html

Hi, for me this error was related to M1 processor. Run tests on a terminal with rosetta enabled and got it working.

In my case we’re missing an await before wairFor from @testing-library/react

- waitFor(() => {

+ await waitFor(() => {
      expect(screen.getByTestId('my-button')).toBeInTheDocument();

If we run with node 16, it does not complain at all. Node 14 yells Call retries were exceeded without any implicit error message and it’s very difficult to spot the bug.

Do not know why but this worked like charm.

In my case, I was not awaiting a findByText. Switching to getByText fixed the issue for me.

My problem was that a testing-library test was longer than the 5 seconds timeout of a test. There are multiples waitFor in it as it represent an E2E test.

@arivestNexapp Another option is you can configure it globally, so you don’t have to manually increase timeout for each test.

import { configure } from '@testing-library/dom';

configure({
  asyncUtilTimeout: 2500,
});

Reference: https://testing-library.com/docs/dom-testing-library/api-configuration#asyncutiltimeout

My problem was that a testing-library test was longer than the 5 seconds timeout of a test. There are multiples waitFor in it as it represent an E2E test.

In order to fix it, I simply needed to up the timeout of the test to an higher value:

it('should do a mega long process`, () => {
  renderComponent();
  
  // all the process
  
  expect(true).toBeTruthy()
}, 60 * 1000) // one minute to be sure it does not timeout again

Hope it helps some of you!

For those having issues running on node 16, I found this link helpful, https://stackoverflow.com/questions/68368577/react-tests-unhandledpromiserejection

Essentially you need to ensure that any custom async functions being called from your tests need to implement a try/catch.

For me the issue came when I used spyon on a api call. Initialy I was using spyOn(dataService, ‘getData’).and.returnValue({ paydown: 0, depAmount: null });

Then it worked when I changed the code to callfake

spyOn(dataService, ‘getData’).and.callFake(() => Promise.resolve({ paydown: 0, depAmount: null }));

Solved with: jest -w 1, hope to help others.

https://github.com/zcorky/moment/issues/26

@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.

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.

“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

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

I’m facing this issue too, any update?

I’m seeing this on Node 10 as well!

@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+

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)