Skip to content

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

Closed as not planned

Description

@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

Activity

  1. lh0x00 commented on Aug 1, 2019

    @lh0x00
    Contributor

    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.

  2. martijnthe commented on Aug 1, 2019

    @martijnthe
    Author

    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.

  3. lh0x00 commented on Aug 1, 2019

    @lh0x00
    Contributor

    Ok, do you provide a reproduce code?

  4. martijnthe commented on Aug 1, 2019

    @martijnthe
    Author

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

  5. fernandoabolafio commented on Nov 26, 2019

    @fernandoabolafio

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

  6. creativecomposer commented on Nov 27, 2019

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

  7. fernandoabolafio commented on Nov 27, 2019

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

  8. degouville commented on Nov 27, 2019

    @degouville

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

  9. nelsieborja commented on Nov 29, 2019

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

  10. davidje13 commented on Nov 30, 2019

    @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 nodejs/node#26628 ? (seems to be the only entry in the Node 13.2.0 changelog which relates to workers)

  11. davidje13 commented on Nov 30, 2019

    @davidje13

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

  12. rafaelcamargo commented on Dec 1, 2019

    @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
    
  13. 79 remaining items

  14. dicutaia commented on Apr 20, 2022

    @dicutaia

    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.

  15. nlasso-longevo commented on Jul 1, 2022

    @nlasso-longevo

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

  16. mohammedabdulai commented on Aug 26, 2022

    @mohammedabdulai

    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.

    It makes sense that a try/catch block solves the issue because it's a way of catching rejections. Essentially all Promises in tests should catch or handle reject.

  17. Temirtator commented on Feb 8, 2023

    @Temirtator

    mostly, If you met such type of problem you need to take an attention to asynchrous test, perhaps problem related with this

  18. johnmutuma5 commented on Mar 10, 2023

    @johnmutuma5

    For me, my problem was with not mocking a dependency exhaustively when some components in the dependency were being used in the component I was testing. For instance

    import { A, B } from "dependency";
    
    MyComponent => ({condition}) => {
      if (condition) 
        return <A /> 
      else
        return <B />
    }

    in my test

    // note B is not mocked, it will be undefined
    jest.mock("dependency", () => ({
       A: (props) => Something
    }))
    
    // condition as false will require B to be defined
    it("shows something", () => {
       <MyComponent condition={false} />
    })

    This would throw this error until I fully mocked the dependency like this (to ensure B is not undefined in the mock):

    // note B will now be defined as the unmocked version
    jest.mock("dependency", () => ({
       ...jest.requireActual("dependency"),
       A: (props) => Something
    }))

    While my component also had some async work, that was never the problem.

    Try to check if you have some things that are undefined possibly due to mocking.

  19. lazy-b commented on Apr 24, 2023

    @lazy-b

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

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

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

  20. kostyaostapuk commented on Oct 3, 2023

    @kostyaostapuk

    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"
    }

  21. marcostomasello commented on Apr 26, 2024

    @marcostomasello

    In my case, it was caused by some unit tests where I forgot to return the promise. Once I added the return keyword it showed me the real reason of the failure (which is specific to my code).

  22. Bharatfegade commented on Feb 24, 2025

    @Bharatfegade

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

    I am getting above issue. Below is the fix i found for this.

    Fix:-
    Change Node Version to v14.21.3
    Change SonarQube Version to 9.9.8.100196

  23. github-actions commented on Feb 24, 2026

    @github-actions

    This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

  24. github-actions commented on Mar 26, 2026

    @github-actions

    This issue was closed because it has been stalled for 30 days with no activity. Please open a new issue if the issue is still relevant, linking to this one.

  25. github-actions commented on Apr 26, 2026

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

  26. locked as resolved and limited conversation to collaborators on Apr 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions