Jest: --detectOpenHandles prints nothing, just hangs

[ronkorving]

🐛 Bug Report

When I run my test suite I get one of these 2 messages:

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.

or

Jest did not exit one second after the test run has completed.
This usually means that there are asynchronous operations that weren't stopped in your tests. Consider running Jest with --detectOpenHandles to troubleshoot this issue.

For one, I think the mention of --runInBand in the first message is probably not necessary. But in any case, when I start running jest with --detectOpenHandles, I get no output, jest just hangs after finishing the tests.

Expected behavior

I would expect detectOpenHandles to give me actionable output.

envinfo

$ npx envinfo --preset jest
npx: installed 1 in 1.775s

  System:
    OS: macOS 10.15.2
    CPU: (4) x64 Intel(R) Core(TM) i7-7660U CPU @ 2.50GHz
  Binaries:
    Node: 10.18.0 - ~/.nvm/versions/node/v10.18.0/bin/node
    Yarn: 1.21.1 - /usr/local/bin/yarn
    npm: 6.13.6 - ~/.nvm/versions/node/v10.18.0/bin/npm
  npmPackages:
    jest: ^25.1.0 => 25.1.0

[f-roland]

confirmed. I saw the same message in the console, ran the command with --runInBand and --detectOpenHandles but it was left hanging

same version of mac os, node 12.13.0, yarn 1.21.1, npm 6.13.6, jest 25.1.0

[jeysal]

Without a repro, this is not actionable. Feel free to reopen if you can provide a minimal (= not just a project with lots of tests and config that may or may not be related to the issue) one.

For one, I think the mention of --runInBand in the first message is probably not necessary.

--detectOpenHandles without --runInBand does not really make sense (unless your tests are already being run in band anyway), since you will be detecting open handles in the main process, while your tests are running in child processes.
We should amend all messages mentioning --detectOpenHandles to also include --runInBand, I've noted to do that at some point.

[abriginets]

@jeysal hello. Please check my repo - umbress. You can find all my tests and configs in there. Also you can go to pull requests tab and see there an ongoing/failed tests for my latest PR - full GitHub Actions logs is there for you to explore :)

In my PC when I start npm test it says

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.

But in Github Actions message is changing to

Jest did not exit one second after the test run has completed.

Edit: --forceExit and --detectOpenHandles has fixed this issue for me, but once again it feels like I'm fighting with only symptoms.

[yolpsoftware]

Same problem here. Please reopen.

[jeysal]

We won't reopen this without a minimal repro. The only repo posted is not useful, since we don't have time to spend on hunting down leaks in big repos for someone, we can only take action when pointed to a concrete problem in Jest. That's why I asked for a minimal repro specifically.

[yolpsoftware]

Okay, gonna try to isolate it.

[Prestaul]

I'm seeing the same issue. I'm not asking for help debugging my code, I'm pointing out a "concrete problem in jest". In some code bases, when running jest with --runInBand --detectOpenHandles, as recommended by the CLI, the tests complete with no reported issues and jest hangs.

I have not been able to isolate a minimal reproduction, but this does not mean the issue isn't real. Unless this is expected behavior, please reopen in acknowledgement that this is clearly affecting users.

[abriginets]

@Prestaul don't bother. They rather ask you to provide minimal repro than actually try to investigate after a bunch of complaints.

[grassator]

Adding leaked-handles package to my Jest setup code and then --runInBand allowed to find which test suit is leaking.

[2imad]

this solves it
"test": "jest --watch --runInBand --detectOpenHandles"

[dgerbe]

this solves it
"test": "jest --watch --runInBand --detectOpenHandles"

This fixed my issue as well, but I think it was really the runInBand option that fixed my particular issue, so it might not that helpful for this bug report.

[jondb]

--detectOpenHandles without --runInBand does not really make sense (unless your tests are already being run in band anyway), since you will be detecting open handles in the main process, while your tests are running in child processes.

Curious if --runInBand is necessary. The documentation (https://jestjs.io/docs/en/cli#--detectopenhandles) suggests --runInBand is implied by --detectOpenHandles.

[levilansing]

I've also hit this a number of times and again today, so I made a minimal repro from my most recent encounter:

https://github.com/levilansing/jest-9473

I'm reasonably certain I've encountered this with timers and promises in the past, but couldn't repro just now. In this repo, I've left a connection open to redis during tests, which should obviously be mocked during tests, but demonstrates that jest does not provide any hint to what might be causing the tests to hang when using --detectOpenHandles in this case.

[mividtim]

Shouldn't this issue be re-opened, now that someone has provided a minimal repro?

[papaiatis]

I'm having the same problem. Tried all suggestions here but to no avail.
@jeysal are you willing to re-open now since a minimal repro is provided?

[lmajowka]

Same problem here, but I am just starting a new project. Should I check other test libraries? any suggestion? thanks

[abriginets]

@lmajowka @papaiatis refer to comment and install the proposed module. For me it was Redis module that was not properly closing the connection. In your environment it will show you some other leaking pipes.

[papaiatis]

@lmajowka @papaiatis refer to comment and install the proposed module. For me it was Redis module that was not properly closing the connection. In your environment it will show you some other leaking pipes.

Yes, I tried that, and it didn't give me any valuable information.
But after all I figured out the root cause of my issue: I was using TypeORM to manage a DB and I had to _explicitly_ close the connection to the DB.

[yolpsoftware]

Why does the library have --detectOpenHandles if you have to install another library to detect the open handles?

Of course you also can find the leaked handles manually by isolating the leaking component, but this does not change the fact that --detectOpenHandles is broken and this ticket should be re-opened.

[loganwedwards]

I am seeing these errors too (even after .skip) all of my tests. However, When adding both --forceExit --detectOpenHandles, the test exists "cleanly" (no warnings). I suspect there is a red herring somewhere that is causing this since I could not find any leaks in my tests (although they may exist). I'm not of the opinion that the combination of those flags listed is a real fix, but the tests did exit properly and without warnings or errors.

[literakl]

What is expected behaviour of --detectOpenHandles? The documentation says that it shall print something. But when I run JEST with this parameter, the test never finishes and there is nothing written at all when I kill the process with Ctrl-C. Am I missing something?

[TarSzator]

I have the same issue.
npm test
leads to

Jest did not exit one second after the test run has completed.

This usually means that there are asynchronous operations that weren't stopped in your tests. Consider running Jest with `--detectOpenHandles` to troubleshoot this issue.

Then
npm test -- --detectOpenHandles
leads to no errors but a slow test run and probably due to a force quit of jest after some timeout

Then
npm test -- --forceExit
leads to the message

Force exiting Jest: Have you considered using `--detectOpenHandles` to detect async operations that kept running after all tests finished?

So executing
npm test -- --forceExit --detectOpenHandles
leads to no warning and messages and a quick end of the test process.

This makes sense but I would rather like to know which handle of mine is still open to close it in a clean way.
So I say this is a bug and should be reopened.

Edit 2020-04-23:

I was able to strip down my project and reproduce the error. Have an assumption what is the reason in my code which causes the issue.
If this assumption turns out to be true I will link a repo here to reproduce it which might help the Jest devs to debug the issue.

Edit 2020-04-24:

Registered timeouts are not detected by the jest "detectOpenHandles" option
Here a repo to reproduce the issue and a fix on client side
https://github.com/TarSzator/jest-open-handle-test

I hope it helps to find the error in Jest or Jest is intended like that then it might help users to find and fix issues on their side.

[roychri]

@jeysal Hi, I can see above that two minimal repros were provided. Is it possible to reopen this?

Thanks!

[jeysal]

I haven't had a chance to take a closer look at any of the comments/repros posted yet, but yeah can reopen even though not sure whether I can look at it myself

[Xunnamius]

Just got bitten by this issue today. Turns out I wasn't closing a MongoDB client connection properly. The Jest behavior was pretty confusing, but this thread helped.

[sravan-s]

In my case there was a setInterval, and clear interval in a react component

For example -

export default function App() {
  const [label, setLabel] = useState(Math.random());
  useEffect(() => {
    const interval = setInterval(() => {
      setLabel(Math.random());
    }, 1000);
    return () => {
      clearInterval(interval);
    };
  }, []);

  return (
    <div className="App">
      <h1>{label}</h1>
    </div>
  );
}

I used
jest.useFakeTimers(); on the test
https://jestjs.io/docs/en/timer-mocks.html and it was fixed

But the original problem --detectOpenHandles should be fixed

[ls-laurent-cobos]

I had same issue but I noticed that it works fine when I specify a path when running my tests

Jest outputs correctly open handles: jest --runInBand --detectOpenHandles src/
Where here I get nothing: jest --runInBand --detectOpenHandles

[renatomariscal]

If the comments here are right that --runInBand is required, there is at least a documentation bug, because it is supposed to be implied.

> jest --help

(...)

--detectOpenHandles           Print out remaining open handles preventing Jest
                                from exiting at the end of a test run. Implies
                                `runInBand`.          [boolean] [default: false]

(...)

On version 26.4.0

[renatomariscal]

None of the previous instructions helped me, I still get it hanging.
Here is a work-around that worked for me:

Install why-is-node-running: npm i why-is-node-running
Edit jest entry point to use it, in my case the file is located in./node_modules/.bin/jest

I made it to look exactly like this:

#!/usr/bin/env node
/**
 * Copyright (c) Facebook, Inc. and its affiliates. All Rights Reserved.
 *
 * This source code is licensed under the MIT license found in the
 * LICENSE file in the root directory of this source tree.
 */

const log = require('why-is-node-running') // should be your first require

setInterval(function () {
  console.log('WILL PRINT ACTIVE HANDLES');
  log() // logs out active handles that are keeping node running
}, 1000)


const importLocal = require('import-local');

if (!importLocal(__filename)) {
  require('jest-cli/bin/jest');
}

Then running jest: ./node_modules/.bin/jest (my params) --runInBand
Got it printing some helpful information every 1 second.

---

Jest code says it is based on why-is-node-running:
https://github.com/facebook/jest/blob/1cc205c274defb24f8b827b8a0c53c161c79d106/packages/jest-core/src/collectHandles.ts#L38

[fbaba-nibtravel]

Hi All, I'm having a similar issue, but only when collecting coverage.
All tests runs fine without the --collectCoverage at the moment I turn this flag on, I start getting some weird issues, including the 2 messages stated on the bug report.

[SpencerKaiser]

For anyone still struggling with this, I managed to narrow down my issue by using a combination of suggestions above. Here's what I did:

1. Ran npx jest --runInBand --detectOpenHandles src/tests to validate that something was indeed hanging
2. Ran npx jest --runInBand --detectOpenHandles src/tests/someDir on several dirs to figure out which one was the culprit (if it doesn't hang and exits cleanly, move on to another dir)
3. Ran npx jest --runInBand --detectOpenHandles src/tests/someDir/someFile to figure out exactly which file was causing the problem
4. Commented out tests within the file to figure out exactly which test(s) were causing the problem

For anyone using NEXT.js, this line was the problem for me: const nextApp = next({ dev: process.env.NODE_ENV !== 'production' });. I'm ripping it out tomorrow and migrating to serving an app directly from Express 😬

Hope this helps someone else out there!

[omgoshjosh]

Hello all. My issue is that running jest produces the "a worker process failed to exit gracefully" but when i try to isolate with the provided CLI args --runInBand and --detectOpenHandles, I am no longer able to produce the error. so... just wanted to throw that out there. i also found this open issue in testing-library:

https://github.com/testing-library/dom-testing-library/issues/524

not sure it's related, but it's something.

[jasonhocker]

We see this problem after updating to jest 26.6.0 and did not see it before that version.

[petrpatek]

Same here.

envInfo:

 System:
    OS: macOS 10.15.7
    CPU: (4) x64 Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
  Binaries:
    Node: 12.18.3 - ~/.nvm/versions/node/v12.18.3/bin/node
    npm: 6.14.8 - ~/.nvm/versions/node/v12.18.3/bin/npm
  npmPackages:
    jest: 26.6.3 => 26.6.3 

Jest cmd: jest --testTimeout=20000 --runInBand --detectOpenHandles

Code example:

describe('Plugin', () => {
    test('should launch browser', async () => {
        await new Promise((resolve) => setTimeout(() => resolve(), 5000));
    });
});

Process hangs. No open handles are logged.

EDIT: I think it might be connected to https://github.com/facebook/jest/issues/10777

[arty-name]

In my case the upgrade from 24.9.0 to 25.0.0 breaks it.

Switching from ts-node to babel/preset-typescript allowed Jest to report an open handle, but fixing it didn't help.

[mukulvashisht1026]

Hi, I am facing the similar issue.
I just write this simple test.

describe('first test', () => {
  it('demo test', () => {
    expect(true).toEqual(true);  
  });
});

But jest is not returning to the terminal after running the test. --detectOpenHandles is also not showing any output.

[jamesandersen]

EDIT: I think it might be connected to #10777

This was the issue for me... I applied the workaround suggested in that issue to get jest to exit again.

[mukulvashisht1026]

EDIT: I think it might be connected to #10777

This was the issue for me... I applied the workaround suggested in that issue to get jest to exit again.

Yes, I think I am also facing a similar issue.