-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jest failing with "Call retries were exceeded", using --runInBand works-around issue #8769
Comments
do you use |
Not that I’m aware of? I do see it as a dependency in my yarn.lock file. I will try to create a minimal repro example when I find some time. |
Ok, do you provide a reproduce code? |
|
Any lucky on this? I am having the same issue after upgrading to node v13. |
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. |
@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. |
Same for me I have the same issue w/ Node 10.17.0 |
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 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 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) |
Appears this issue has been reported upstream: nodejs/node#30730 |
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
Then
|
(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 EnvironmentI had this error with 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(); |
Believe got same issue on Node LTS 12.14.1:
|
What helped me was upgrading the runner machine to the one with more memory. |
@mvasin how much memory has your machine now? |
same with node 10.19.0, ubuntu 20.04 |
Working version for our builds: 12.16.3 Running 16GB memory, 8cpu on circleCI with the following options
|
adding |
This is an attempt to work around jestjs/jest#8769.
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 ! |
I am seeing a similar issue with node v16.10.0. In my case, however, I am running locally and
Reverting back to node 12.20.1 resolves the issue but it seems like more than just a node version problem. |
Similir problem here! Not working on 14 and 16, but works on node 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.
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 Would it be possible to bubble up those Jest 27.2.3 |
Having the same problem jest: 26.6.3
|
Same issue here |
jamesRaybould's description matches the problem I have as well. Worked in node 14.17.16, fails in 16.13.0. |
In my case we're missing an - waitFor(() => {
+ await waitFor(() => {
expect(screen.getByTestId('my-button')).toBeInTheDocument(); If we run with node 16, it does not complain at all. Node 14 yells |
Same Problem here:
Node version: Does anyone got a fix? |
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 |
I had the same problem with a VueJS app, with nodejs v16.13.0 and jest 25.5.4 so a bit older version of Jest.
and "Fixed" it with the following changed. I prefer the former syntax than the latter.
to
|
Do not know why but this worked like charm. |
For those having issues running on node 16, I found this link helpful, Essentially you need to ensure that any custom async functions being called from your tests need to implement a try/catch. |
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 Passing that flag may work as a short term workaround. |
My problem was that a testing-library test was longer than the 5 seconds timeout of a test. There are multiples In order to fix it, I simply needed to up the timeout of the test to an higher value:
Hope it helps some of you! |
@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 |
In my case, I was not awaiting a |
Hi, for me this error was related to M1 processor. Run tests on a terminal with rosetta enabled and got it working. |
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. |
mostly, If you met such type of problem you need to take an attention to asynchrous test, perhaps problem related with this |
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 // 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. |
全体起立! process.on('unhandledRejection', (reason) => {}); |
I was trying to run the craco tests and I got the error:
I added the option for Node.js for
My package.json:
|
In my case, it was caused by some unit tests where I forgot to return the promise. Once I added the |
🐛 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:
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:
Local:
The text was updated successfully, but these errors were encountered: