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

@lucasfcosta Every time I’ve tried using --detectOpenHandles in my test code in a few different applications over the years it has never provided me with any useful output. It just sits there waiting for everything to wrap up but without printing the warning that suggests to use the argument in the first place. Is there some trick to getting useful output from that argument that I am unaware of?

I was getting the same error in one of my integration tests. In it, I was using a Sequelize Model to setup the database to a known state in beforeAll or beforeEach. The fix was to call close on the Sequelize instance connected to the Model in the afterAll callback. Hope this helps someone else.

EDITED:

And by popular request, here is effectively what I’ve done:

# dbConnection.js
export default new Sequelize({...}); // The Sequelize instance.

# some.spec.js
import dbConnection from './dbConnection';

const { SomeModel } = dbConnection.models;

describe('...', () => {
  beforeEach(async () => {
      await SomeModel.create({...});
  });
  ...
});

afterAll(async done => {
  // Closing the DB connection allows Jest to exit successfully.
  dbConnection.close();
  done();
});

@Shrikant9 @AnitaMartinez

I added an example.

Try putting “done” inside the callback from the test function as so:

const whateverYouExpect = 123;
test('some description of test', async (done) => {  
    await someAsyncTask();  
    await secondAsyncTask();  
    evenCallbacksCanWork((result) => {  
        expect(result).toBe(whateverYouExpect);  
        done();
    });  
})

Additionally, if a connection is being kept open, this will also stop the test from completing, so closing any open connection would be recommended as well.

Is there any other way to debug? --detectOpenHandles is not showing any output. Thanks

I was getting the same error in one of my integration tests. In it, I use mongo. The fix was to call close on the mongoose.connection . Hope this helps someone else.

const mongoose = require('mongoose')
describe(' ...... ', ()=>{
  afterAll( async () =>{
        await mongoose.connection.close()
    })
})

I’ve been having this problem too

I ended up using https://www.npmjs.com/package/why-is-node-running logging in beforeAll

import log from 'why-is-node-running';

afterAll(async () => {
  //normal cleanup things
  await new Promise(resolve => {
    setTimeout(() => {
      log()
      resolve()
    }, 4000)
  })
}

turns out that since I was using jest.resetModules, I had to reimport the module that was using a pg connection and close it there too.

I have run into the same issue with globalSetup and globalTeardown hooks, but I can’t find any processes left unattended. I added done() to the end of all the tests, and I am stopping my server during teardown.

jest --runInBand --detectOpenHandles doesn’t print anything to the console.

I have run into the same issue with globalSetup and globalTeardown hooks, but I can’t find any processes left unattended. I added done() to the end of all the tests, and I am stopping my server during teardown.

jest --runInBand --detectOpenHandles doesn’t print anything to the console.

Facing same issue tried closing sequelize connection , no luck there. Even though the issue might not be with jest but its main problem is it doesn’t display which processes are active --detectOpenHandles doesn’t print anything 😕 On the top if we use --forceExit it shows message to use --detectOpenHandles Irony 👎

Hello everyone,

Please correct me if I’m wrong but this seems like an issue which is not on Jest’s side.

If you want the tests to exit even when there are external resources being held I think you should use --forceExit. The forceExit flag is specifically designed for this case and therefore is an indication that tests not exiting when it’s not present is indeed an expected behaviour and not a bug.

Force Jest to exit after all tests have completed running. This is useful when resources set up by test code cannot be adequately cleaned up. Note: This feature is an escape-hatch. If Jest doesn’t exit at the end of a test run, it means external resources are still being held on to or timers are still pending in your code. It is advised to tear down external resources after each test to make sure Jest can shut down cleanly.

As the author mentioned, it’s possible to use --detectOpenHandles for debugging this (and this is also mentioned in the docs btw).

Given the arguments above, perhaps this issue could be closed?

I was having this problem with Knex and using global setup and teardown files on Jest.

My solution was:

// setup.js
const knexConfiguration = require('../config/knex')[process.env.NODE_ENV];
const knex = require('knex');

const setup = async () => {
  const client = knex(knexConfiguration)
  await client.migrate.latest();
  await client.destroy();
};

module.exports = setup;

// teardown.js
const knexConfiguration = require('../config/knex')[process.env.NODE_ENV];
const knex = require('knex');

const teardown = async () => {
  const client = knex(knexConfiguration)
  await client.migrate.rollback();
  await client.destroy();
};

module.exports = teardown;

Hope it helps anybody facing this kind of problem.

Had this problem with tests that used firebase. This fixed it:

beforeAll(async () => {
  await firebase.firestore().enableNetwork();
});

afterAll(async () => {
  await firebase.firestore().disableNetwork();
});

For anyone running into this using sequelize, I had to do this:

  afterAll(async done => {
    await models.sequelize.close();
    done();
  });

That fixed the issue.

It’s extremely disappointing that after almost 3 years there seems to have been zero effort to resolve this issue and make detection of unresolved promises any easier. Ideally node itself would make this an easier issue to debug. I don’t know how many days I’ve lost over the years trying to debug these kinds of issues.

Another possible reason I faced – not closed Redis connection.

afterAll(async done => {
   globalRedisClient.unref();
   done();
});

I’m testing Jest with mongoose and supertest, add testEnvironment: 'node' fixed this issue for me.

If you’ve multiple test files, I use global setup and teardown. For example in jest.config.js I defined:

module.exports = {
    globalSetup: './setupTests.js',
    globalTeardown: './teardownTests.js',
};

In setupTests I connect to the db and return a function which returns a promise. Similarly in teardownTests I close the db connection and return a function which returns a promise.

I had tests that were checking auto generated http server and socket.io connections. The tests were running fine on my windows machine, but failing for not exiting on my Jenkins server.

I was closing both the socket.io server and http server correctly at the end of the test, but I was not closing the clients. Once I added the cleanup for the clients, the tests exited successfully on their own on both my dev machine and CI server.

The tests would work without closing the clients if I used --forceExit, but at the end of the day, the real problem was improper cleanup.

I also found that --detectOpenHandles did not produce any output.

I’m also having this problem. To give some context, I am using SuperTest to do some e2e testing with MongoMemoryServer. My setup and teardown looks like this:

let mongoServer;

beforeAll(async (done) => {
  mongoServer = new MongoMemoryServer({ instance: { port: 26016 } });
  const uri = await mongoServer.getUri();
  process.env.MONGODB_URI = uri;
  done();
});

afterAll(async (done) => {
  await mongoServer.stop();
  done();
}); 

Nothing out of the ordinary that would suggest that I’m following the documentation wrong. I started troubleshooting by looking at Activity Monitor on MacOS. It seems that there are two node processes that are still running whilst jest is running. However, as soon as I cancel / quit the test run, the processes also quit.

I’m going to investigate further by sampling the node processes and see exactly what spawns them. I will update here with my findings.

EDIT: Related issue #1456 - it looks like it’s an underlying NodeJS issue. tl;dr - add the --forceExit flag to your test script in package.json

Same here. I get no output from --detectOpenHandles.

$ yarn test:types && jest --config ../../jest.config.js --detectOpenHandles
$ tsc --noEmit
 PASS  src/App.test.tsx (9.447s)
  √ renders without crashing (240ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        10.201s, estimated 14s
Ran all test suites.
(node:9784) UnhandledPromiseRejectionWarning: Error: connect ECONNREFUSED 127.0.0.1:80
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1126:14)
(node:9784) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a prom
ise which was not handled with .catch(). (rejection id: 2)
(node:9784) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-z
ero exit code.

My jest.config.js:

module.exports = {
  bail: true,
  collectCoverage: false,
  collectCoverageFrom: ['src/**/*.{ts,tsx}', '!src/index.tsx', '!src/main.ts', '!**/node_modules/**'],
  coverageDirectory: '<rootDir>/coverage',
  coverageThreshold: {
    global: {
      branches: 100,
      functions: 100,
      lines: 100,
      statements: 100,
    },
  },
  moduleFileExtensions: ['js', 'json', 'jsx', 'ts', 'tsx'],
  rootDir: process.cwd(),
  testMatch: ['<rootDir>/src/**/*.test.{ts,tsx}'],
  transform: {
    '^.+\\.tsx?$': 'ts-jest',
  },
  verbose: true,
};

My test case:

import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';

it('renders without crashing', () => {
  const div = document.createElement('div');
  ReactDOM.render(<App />, div);
  ReactDOM.unmountComponentAtNode(div);
});

Thank you ExoMemphiz, but this callback, from where should I reachit?

It’s too deep inside the server.

I moved to Ava, it works out of the box 👍

After losing hope to detechOpenHandles and --runInBand and their combination, I have finally managed to solve it without using them. I was having a similar problem while mocking ioredis.

Now, Previously I was simply mocking (jest.mock('../path/redis.ts')) the Redis client file (redis.ts) which was not working.

import IORedis from "ioredis";

const client = new IORedis({
    host: process.env.REDIS_HOST || "redis",
    port: Number(process.env.REDIS_PORT) || 6379
});

export default client;

To solve this, I have changed the way to mock the client library as per the requirement. In a helper, I was using this library’s hmset function, and for the unit test of the helper I needed to mock the same.

The following way of mocking has worked successfully.

jest.mock("../../src/config/redis", () => {
    return { hmset: jest.fn() };
});

You can include more functions (hdel, hmget, etc) of Redis client as per the requirement.

I hope this helps 🙏

@BigsonLvrocha thank you for that idea re: why-is-node-running! In my case that tool showed me that redux-state-sync was being initialized in tests, which has an infinite loop to listen for Redux updates in it. --detectOpenHandles did not output anything for me, either.

–watchAll=false in ci environment

Well well, my danish brother 😃

The problem is that I’m using mongoose to save something async when I call this api, and I cannot reach this code to figure out when it’s finished saving the document inside mongo.

await server.inject

The code above actually wait for the response only, and it works, but jest complain about the mongoose save, it still in progress saving behind the scene.

I tried to disconnect mongoose, and close each connection, but it doesn’t work.

I was able to fix the issue for me in this way. 🥳

I first ran my test package.json script with the additional command of ps -e | grep node. Like this: $ yarn run test && ps -e | grep node

So I could see which node processes are running after jest process has been finished. In my case two intellij language node processes and my microsoft teams desktop client were running. (remark: microsoft teams desktop client is running as a react native app on node js on your local machine)

To verify if my assumption is correct I closed intelliJ and my MS Teams Client and started the same script in my terminal. It worked fine. I didnt get the warning anymore.

To be double assure I startet my MS Teams Client again and startet the test script in my terminal again. I got the warning again.

Conclusion: It seems that jest is considering other node processes as application processes. This shouldn’t be the case. I hope this helps to give a hint to fix this issue 😃

I have a similar problem with a database connection with knex. After call connection.destroy() on afterAll(), the message has gone.

What if I’m not calling a database ? What if I’m calling an external resource of which I have no control ? How do I “close” ?

Hello! It seems like you haven’t yet disconnect to the database. I’ve been try mongoose.disconnect() in afterAll() function and it don’t show message like that anymore.

My solution won’t work for everyone, but if you scoured the web for as long as I did trying to figure out how to close that damn handle that was left open, this might help. In my ecosystem, we are running a Parse Server as middleware with an Express server, but this could apply to anyone who needs to run a separate server with the tests but is unable to close some socket or port at the end. I believe the issue causing the dreaded “Jest did not exit one second…” error for us was a result of Parse’s MongoDB adapter not closing correctly.

So to get around this issue, I abstracted the server initialization completely out of the jest test suite and created a special npm script to run it in an entirely separate process.

NPM Script (package.json):

"scripts": {
    "test": "npm start & ./listen_on_port_5000.sh && jest test && kill $(lsof -t -i tcp:5000)",
}

listen_on_port_5000.sh

while ! nc -z localhost 5000
do
    sleep 0.5
done

So how does this work?

1. npm start runs which is the normal command we would run to start our server with Express and Parse.
2. Because we know that the server always starts on port 5000, we run the start script in the background and start a separate process running a shell script (listen_on_port_5000.sh) to wait for the server to boot up.
3. Once the listener script detects anything running on port 5000, the npm script moves onto the jest command (all while the Express server is up and running).
4. When Jest finishes running, the final script runs a kill script to close the server running on port 5000.

Hi, I was getting the same error, with @dhurlburtusa tip, my code was @AnitaMartinez, I’m new in TypeScript, so I’m pretty sure this can be done in a better way:

let conn: Connection;
const createGlobalDatabaseConnection = (fn: Function) => dbConnection().then((conn: Connection) => fn(conn));

createGlobalDatabaseConnection((connection: Connection) => {
    conn = connection;
});

const closeGlobalDatabaseConnection = async () => {
    await conn.close();
}

afterAll(async () => {
    await closeGlobalDatabaseConnection();
});

The dbConnection Promise is the function that actually connects to the database instance.