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

[francois-codes]

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.

[iyo-bemoore]

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!

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

[vighnesh153]

@jeysal I tried to produce a small example but this doesn't happen on small projects. Nonetheless, here is a project, it just has 5-6 routes and a react-client. Just remove the --detectOpenHandles --forceExit flags from the test script in package.json to reproduce the error. Hope this helps to detect the issue.

[track0x1]

Fixed this by doing the following (not sure if all steps are necessary but it worked):

npm i -D fsevents@latest
npm dedupe
npm uninstall -D fsevents

Confirm fsevents is bumped to at-least 2.2.1 for jest's dependencies by running npm ls fsevents.

[hasezoey]

@track0x1 what system were you on? windows / mac / linux / something else?

[track0x1]

@hasezoey This was on a mac

[DullReferenceException]

FWIW, I have this same issue on Linux which isn't installing fsevents at all.

[jasonlimantoro]

For anyone struggling with this issue and using ioredis package:
A simple fix would be to quit the redis connection in your afterEach or afterAll hooks:

// src/lib/redisClient.js # whatever path you instantiate the package
export const redis = new Redis(config.REDIS_URL);

import { redis } from "src/lib/redisClient";

// tests/setupTest.js
afterAll(async () => {
    await redis.quit();
});

Referring from: redis/ioredis#1088 (comment)

[salvadordiaz]

For anyone having troubles with tests using vue-test-utils that get stuck, don't forget to await calls to Wrapper methods that return a Promise from $nextTick().

For example, I had a test that called wrapper.setProps({}) inside a for loop and it made jest hang and the solution was to await the setProps calls.

I hope this helps someone.

[Jule-]

I come here to share my experience.

TL;DR: in my case it was my unclosed database connections that was triggering this log...

Long version:
I use Jest to run backend tests, so in my tests I use supertest which starts my express app which starts MongoDB connections with mongoose... And obviously after my tests are finished, I did not close my connections, pretty far from my thoughts when I firstly saw this issue... Then for me this is what fixed my issue:

afterAll(async () => {
  for (const connection of mongoose.connections) {
    await connection.close();
  }
});

In order to reproduce:

import request from "supertest";
import app from "./app";
/**
 * app:
 * - an express() app instance
 * - with an endpoint `/api/test` for example
 * - which requires a mongoose Model with an active connection
 */

describe('description', () => {
  it('description', async () => {
    const req = await request(app).post("/api/test");
  })
});

HTH

[laurent22]

in my case it was my unclosed database connections that was triggering this log...

The problem is not really what triggers this log, as that varies from user to user. The problem is that --detectOpenHandles makes Jest freezes instead of printing information.

[Jule-]

@laurent22 Indeed, I agree, just wanted to share in order to help people working around until Jest can give more info on what is locking the process. I felt that my case is a pretty common usage.

[mattcarlotta]

I had a similar issue to @Jule-, but it was how I was making a connection to Mongo via mongoose. It seems like mongoose's mongoose.connection.close() in a top-level afterAll within a setupTests file isn't consistently closing the connection.

My approach was to set up a single connection before all tests within a setupTests.ts file to register mongoose models, then close the single connection after all test suites have finished. This appears to cause issues with Jest.

For example:
database/index.ts

const options = {
  useNewUrlParser: true, // avoids DeprecationWarning: current URL string parser is deprecated
  useCreateIndex: true, // avoids DeprecationWarning: collection.ensureIndex is deprecated.
  useFindAndModify: false, // avoids DeprecationWarning: collection.findAndModify is deprecated.
  useUnifiedTopology: true // avoids DeprecationWarning: current Server Discovery and Monitoring engine is deprecated
};

export const connectToDatabase = (): Promise<typeof mongoose> =>
  mongoose.connect(`mongodb://localhost/${DATABASE}`, options);

setupTests.ts (this works about 50% of the time unless I used --runInBand, then it worked fine)

import mongoose from "mongoose";
import { connectToDatabase } from "~database";

beforeAll(async () => {
  await connectToDatabase();
});

afterAll(() => {
  mongoose.connection.close();
});

Instead, removing the setupTests.ts file and moving the connection within each test suite seems to have fixed the warning:

 import mongoose from "mongoose";
 import { connectToDatabase } from "~database";

 describe("Example", () => {
   beforeAll(async () => {
     await connectToDatabase();
   });

   afterAll(async () => {
     await mongoose.connection.close();
   });

   it("...", () => {});
 });

[ronkorving]

@laurent22 is exactly right. This thread is not about posting workarounds, which is what this has become. Nothing against everyone sharing info. Without any official response that is actually useful, that's what happens.

Given that there's clearly no intention to fix this, I guess it's time for me to unsubscribe from my own bug report. Sigh.

[ZobairQ]

jest --forceExit --detectOpenHandles this solves the problem for me

[daguitosama]

For anyone struggling with this issue and using ioredis package:
A simple fix would be to quit the redis connection in your afterEach or afterAll hooks:

// src/lib/redisClient.js # whatever path you instantiate the package
export const redis = new Redis(config.REDIS_URL);

import { redis } from "src/lib/redisClient";

// tests/setupTest.js
afterAll(async () => {
    await redis.quit();
});

Referring from: luin/ioredis#1088 (comment)

I have experienced the same problem with a ioredis using test, solved as proposed. It looks like the test process hangs with the redis open connection

[SimenB]

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

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.

Using jest@next detects 2 handles:

stack trace of the first one isn't suuuuper useful, but it's something pointing to redis at least 🙂

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

Same here

---

As far as I can see, these are the only 2 reproductions posted, which have both been fixed (in #11429 🚀), so I'll close this one as it's suuuuper long and full of workarounds and "+1"s.

One improvement I want to make is print "sorry, we found no open handles" or some such so it doesn't seems like Jest didn't react to the flag.

---

If somebody using Jest 27 or newer (try out jest@next, stable will come next week) still have this issue, please open up a new one with a minimal reproduction (like the two I checked here).

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.