Dom-testing-library: 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?

[favs-sama]

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?

[nickmccurdy]

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: https://github.com/facebook/jest/issues/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 https://github.com/facebook/jest/issues/10777 and fsevent bug https://github.com/fsevents/fsevents/issues/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