dom-testing-library: jest run reports "A worker process has failed to exit gracefully ..."

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?

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?

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..
})

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.

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

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

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 🤷🏻‍♂️

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.

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

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

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

Are you all running jest using a Mac? If so it may be related to https://github.com/facebook/jest/issues/10777 and fsevent bug https://github.com/fsevents/fsevents/issues/345 that has just been fixed 🤔

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

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

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.

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

Could be a regression of #801 ? @kentcdodds

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