jest run reports "A worker process has failed to exit gracefully ..."

[deej-split]

• DOM Testing Library version: 7.2.1
• node version: 10.15.3
• npm (or yarn) version: 6.13.6

Relevant code or config:

require('@testing-library/dom');

What you did:

See above.

What happened:

Jest (?) is reporting the warning A worker process has failed to exit gracefully and has been force exited. This is likely caused by tests leaking due to improper teardown. Try running with --runInBand --detectOpenHandles to find leaks. at the end of a test run

Reproduction:

Probably pretty hard. See below.

Problem description:

The problem is that when we require('@testing-library/dom');. (even if we never call configure() or any other RTL code) at the end of the test run of 3500 tests we get the above warning. Trying to subdivide the tests to find the "offending test", makes the problem go away. So, it isn't directly due to some misbehaving test.

Interestingly, if we use require('@testing-library/react'); and do not directly import .../dom we don't see the problem.

I'm not seriously expecting that you can fix this given the paucity of information I have to offer. And given that we're on React 15, node 10 (though current Jest) it is entirely possible that this is a result of some older version of things that doesn't happen on newer configurations. Instead, I'm filing this mainly to let you know this is happening, and to leave a record to allow others to know that someone else has seen this problem.

(the workaround appears to just be to not do any configuration of @testing-library/dom :-)

[alexkrolick]

👋 Deej

This is tricky. Importing DTL/index is synchronous, so it shouldn't really do anything that causes Promises or timeouts to leak... I assume your tried Try running with --runInBand --detectOpenHandles to find leaks. and it didn't yield any useful info?

The only kind of suspicious thing I can think of is that importing screen could maintain a reference to document.body that is tied to the JSDOM instance that was present when it was created. This was added in v6.11.0.

[deej-split]

@alexkrolick 👋

Yes, I should have mentioned I did try with the runInBand and detectOpenHandles. And "of course" the problem went away when I did that.

And the @testing-library/dom we're getting is 7.2.1

🤷
Again, not asking for a fix, just recording that it happens.

[SarthakJha]

is the command suppose to be jest --runInBand --detectOpenHandles

[deej-split]

@SarthakJha I think so. Why do you ask?

[favsss]

I am able to reproduce permanently in one of my tests, mine has something to do with a mocked function that is used with the await js keyword

[deej-split]

@favs-sama I assume it is too complex to extricate that out into a repeatable simple test case?

[rmcsharry]

Node v12.14.1
Angular 9.1
Jest 25.2.7

We also see this message.

jest --runInBand --detectOpenHandles does not yield anything.

Is there some way to identify which tests might be leaking?

[nickserv]

You could try only running specific test files until you can isolate which ones are causing issues with open handles. If it's many of them, you should check your setup scripts and test utilities.

[omgoshjosh]

so i only see this when i run the whole suite. in my test files, there are maybe 5 directories that contain all tests and running each one like jest dir1 and jest dir2 yields no message, but running the full suite with simple jest does show the message. but when i run it with detectOpenHandles, the message goes away. am i going crazy?

[deej-split]

@omgoshjosh Not going crazy (well, maybe you are, that's independent of this ;-) ). That's exactly what I see too. I spent some time at one point pruning down the set of tests, hoping to isolate "the one bad test" causing this. but, as I recall eventually the problem seemed more a function of number of tests and it doesn't seem tied to any individual test in any obvious way.

[omgoshjosh]

yes and even when i run a large subset, i can get the error to appear sometimes and disappear other times. it seems possible that the timing of the suite may have an impact.

[tonystaark]

I am running only one test file and it throws this error. No idea why it happened

[deej-split]

@tonystaark if it is a single test and it is repeatable, is it something you could share in some way? Might help the maintainer to hunt it down.

[jensbodal]

I see this error in a test package for backend code (i.e. doesn't involve react, this library, or the dom)

So this can probably be closed. Relevant jest issue: jestjs/jest#9473

[yvele]

This error suddenly appears today after having updated dependencies (no semver major updates) 🤔

A worker process has failed to exit gracefully and has been force exited. This is likely caused by tests leaking due to improper teardown. Try running with --detectOpenHandles to find leaks.

Test Suites: 113 passed, 113 total
Tests:       494 passed, 494 total
Snapshots:   134 passed, 134 total
Time:        14.17 s
Ran all test suites matching /\/test\//i.

Node.js v12.19.0
jest 26.6.3

If I rollback to previous dependency versions I don't longer have the error 🤔

Edit: I don't have React as dependency

[marcosvega91]

Could be a regression of #801 ? @kentcdodds

[kentcdodds]

Possibly, I'm not sure though. cc @romain-trotard

[yvele]

Are you all running jest using a Mac? If so it may be related to jestjs/jest#10777 and fsevent bug fsevents/fsevents#345 that has just been fixed 🤔

[seancwalsh]

I presume there's another issue people are referring to here, but just incase someone finds themselves reading. For me deleting node modules and the yarn lock file then re installing dependencies resolved this issue 🤷🏻‍♂️

[osedoe]

In line with @seancwalsh, I can confirm that doing a clean install and bumping Jest to 26.6.3 seems to fix it.

https://github.com/facebook/jest/releases/tag/v26.6.3

[kentcdodds]

Sounds like this is unrelated to Testing Library, so I'm going to close it :) Thanks everyone!

[luistak]

In my scenario, there were two different histories In the same test

I fixed this issue by changing every jest history creation from createBrowserHistory to createMemoryHistory

[FahmyChaabane]

I did face the same thing in 2021,
A node v14.15.5 project. i did use jest 26.6.3 for my testing.
Had only passed the --detectOpenHandles option, and Voila, the warning was gone.

[sam-621]

2 things that help me to troubleshoot this issue

• make sure that you don't have any setTimeOut function
• Use done() callback where you think is the issue

My problem was that I was trying to close an expressjs server but took time.

// this was not working
  afterAll((done) => {
    await server.close();
    done();
  });

//this worked
  afterAll((done) => {
    server.close(() => {
      done();
    });
  });

To solve the problems that are about timers, use jest.useFakeTimers();

describe('my suit of tests', () => {
    jest.useFakeTimers();
    // my tests..
})

[stephmajor]

I can get this all the time when using a utility package I use for my work (jest 26.6.3, node 12.20)

isolated test:

import { convertHtmlToDelta } from 'node-quill-converter';

afterAll(() => {
    // tried to get rid of the offending module to no avail
    jest.resetModules();
    jest.resetModuleRegistry();
    delete require.cache[require.resolve('node-quill-converter')];
});

describe('convertHtmlToDelta', () => {
    const htmlContent = `
        <!DOCTYPE html>
        <html>
            <body>
                some text
            </body>
        </html>
    `;

    it('converts HTML to quill delta JSON', () => {
        const delta = convertHtmlToDelta(htmlContent);
        expect(delta).toMatchInlineSnapshot(`
            s {
              "ops": Array [
                Object {
                  "insert": "some text",
                },
              ],
            }
        `);
    });
});

BTW, this package uses jsdom internally.

[parzhitsky]

For anybody who gets here through search results, – try to check if you are really not forgetting to .close() all your connections with databases, etc, – something that jest cannot figure out to close on its own. In my case, this was exactly that.

[skrenes]

Thanks @parzhitsky! It turns out I needed this for proper shutdown of the pg-promise resources:

afterAll(() => {
  db.$pool.end();
});

[tachyon-ops]

I also saw this with my tests... hunted down the specific file, isolated the test and... used "setTimeout" to construct the rendered comp. Figuring exactly the piece of code is really hard, and I assumed it was probably due to some Promise deep inside my component tree (really big ... 😥).

Updated my package.json:

-    "jest": "^27.3.1",
+    "jest": "^27.4.2",

And now I don't see the issue anymore... though I am really curious to see what changed between 27.3 and 27.4 now.

[WalterWeidner]

We ran into this issue in our tests and it turned out to be someone using waitFor() in their test.

Ultimately, it seems like the cause is that RTL is configured to timeout tests at 1s (per this documentation) and Jest is configured to kill its workers after 500ms (see their source). Changing our default RTL config to timeout at less than 500ms fixed things for us.

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

configure({ asyncUtilTimeout: 400 });

[ahayes91]

Ultimately, it seems like the cause is that RTL is configured to timeout tests at 1s (per this documentation) and Jest is configured to kill its workers after 500ms (see their source). Changing our default RTL config to timeout at less than 500ms fixed things for us.

Yikes, I didn't realise that - I've had performance issues with RTL tests in the past (e.g. #820) where one of the solutions was to up the jest timeouts and asyncUtilTimeout a bit. Going that low would probably cause a lot of tests to fail for us 🤔