Jest has identified a single open handle that may be preventing Jest from exiting: TCPSERVERWRAP

Question

Jest has identified a single open handle that may be preventing Jest from exiting: TCPSERVERWRAP

Currently, I am conducting a basic end-to-end testing procedure which seems to be failing at the moment. The primary issue I am facing is being unable to resolve an open handle.

A result of running all test suites reveals that Jest has identified one open handle that may prevent Jest from exiting:
  
  ● TCPSERVERWRAP

      40 |     }
      41 |     return request(app.getHttpServer())
    > 42 |       .post('/graphql')
         |        ^
      43 |       .send(mutation)
      44 |       .expect(HttpStatus.OK)
      45 |       .expect((response) => {

      at Test.Object.<anonymous>.Test.serverAddress (../node_modules/supertest/lib/test.js:61:33)
      at new Test (../node_modules/supertest/lib/test.js:38:12)
      at Object.obj.<computed> [as post] (../node_modules/supertest/index.js:27:14)
      at Object.<anonymous> (app.e2e-spec.ts:42:8)

import { Test, TestingModule } from '@nestjs/testing'
import { HttpStatus, INestApplication } from "@nestjs/common";
import * as request from 'supertest'
import { AppModule } from '../src/app.module'

describe('AppController (e2e)', () => {
  let app: INestApplication

  beforeEach(async () => {
    const moduleFixture: TestingModule = await Test.createTestingModule({
      imports: [AppModule],
    }).compile()

    app = moduleFixture.createNestApplication()
    await app.init()
  })

  afterAll(async () => {
    await app.close()
  })

  it('/ (GET)', () => {
    return request(app.getHttpServer())
      .get('/')
      .expect(HttpStatus.OK)
      .expect('Hello World!')
  })

  it('mutation', async () => {
    const mutation = {
      query: `mutation Create($title: String!) {
        create(title: $title) {
          id,
          title
        }
      }`,
      variables: {
        title: 'Mon programme',
      },
    }
    return request(app.getHttpServer())
      .post('/graphql')
      .send(mutation)
      .expect(HttpStatus.OK)
      .expect( (response) => {
        expect(response.body).toBe({
          id: expect.any(String),
          title: 'Mon programme',
        })
      })
  })
})

Can anyone help identify what might be causing the obstruction in the test runner?

It is worth noting that I am utilizing NestJs and therefore should not require the use of the .end(done) method at the conclusion of the test.

P.S.: It appears there is an excess of code provided in this question, but I am unsure what additional details could be included.

typescript jestjs graphql nestjs supertest

Answer 1

Answer №1

I have not yet discovered the ideal solution, but for now I have decided to use this workaround :

jest --config ./test/jest-e2e.json --forceExit

The --forceExit option helps terminate openHandles and resolve any lingering issues. However, I am still in search of the "correct way" to address this problem.

Answer 2

I have not yet discovered the ideal solution, but for now I have decided to use this workaround :

jest --config ./test/jest-e2e.json --forceExit

The --forceExit option helps terminate openHandles and resolve any lingering issues. However, I am still in search of the "correct way" to address this problem.

Answer 3

Answer №2

This is the issue at hand

  it('/ (GET)', () => {
    return request(app.getHttpServer())
                  ^^^^^^^^^^^^^^^^^^^^^
      .get('/')
      .expect(HttpStatus.OK)
      .expect('Hello World!')
  })

The problem lies in not closing the server after the test, leading it to remain open. To solve this, you should create a variable to hold the instance and close it after each test. It took me some time to figure this out, and I hope it helps others facing similar challenges.

Below is an example of your code with my suggested fix:

describe('AppController (e2e)', () => {
  let app: INestApplication
  let server: SERVER_TYPE

  beforeEach(async () => {
    const moduleFixture: TestingModule = await Test.createTestingModule({
      imports: [AppModule],
    }).compile()

    app = moduleFixture.createNestApplication()
    await app.init()
    // Reference the server instance
    server = app.getHttpServer()
  })

  afterEach(async () => {
    await app.close()
    // Close the server instance after each test
    server.close()
  })

  it('/ (GET)', async () => {
    // Make the request on the server instance
    return await request(server)
      .get('/')
      .expect(HttpStatus.OK)
      .expect('Hello World!')
  })

I also noticed that you're using beforeEach and afterAll. Creating a new app for each test may cause issues for the HTTP server. However, this is just my opinion.

import { Test, TestingModule } from '@nestjs/testing'
import { HttpStatus, INestApplication } from "@nestjs/common";
import * as request from 'supertest'
import { AppModule } from '../src/app.module'

beforeEach(() => {
  ...
})

afterEach(() => {
  ...
})

describe('tests', () => {
  ...
})

But ultimately, it's up to you and your preference. :)

UPDATE: Corrected the use of beforeEach instead of beforeAll since we need to close the server before EACH test, not globally.

UPDATE 2: Utilizing async/await is crucial, as the request is asynchronous and needs to be awaited for completion.

Answer 4

This is the issue at hand

  it('/ (GET)', () => {
    return request(app.getHttpServer())
                  ^^^^^^^^^^^^^^^^^^^^^
      .get('/')
      .expect(HttpStatus.OK)
      .expect('Hello World!')
  })

The problem lies in not closing the server after the test, leading it to remain open. To solve this, you should create a variable to hold the instance and close it after each test. It took me some time to figure this out, and I hope it helps others facing similar challenges.

Below is an example of your code with my suggested fix:

describe('AppController (e2e)', () => {
  let app: INestApplication
  let server: SERVER_TYPE

  beforeEach(async () => {
    const moduleFixture: TestingModule = await Test.createTestingModule({
      imports: [AppModule],
    }).compile()

    app = moduleFixture.createNestApplication()
    await app.init()
    // Reference the server instance
    server = app.getHttpServer()
  })

  afterEach(async () => {
    await app.close()
    // Close the server instance after each test
    server.close()
  })

  it('/ (GET)', async () => {
    // Make the request on the server instance
    return await request(server)
      .get('/')
      .expect(HttpStatus.OK)
      .expect('Hello World!')
  })

I also noticed that you're using beforeEach and afterAll. Creating a new app for each test may cause issues for the HTTP server. However, this is just my opinion.

import { Test, TestingModule } from '@nestjs/testing'
import { HttpStatus, INestApplication } from "@nestjs/common";
import * as request from 'supertest'
import { AppModule } from '../src/app.module'

beforeEach(() => {
  ...
})

afterEach(() => {
  ...
})

describe('tests', () => {
  ...
})

But ultimately, it's up to you and your preference. :)

UPDATE: Corrected the use of beforeEach instead of beforeAll since we need to close the server before EACH test, not globally.

UPDATE 2: Utilizing async/await is crucial, as the request is asynchronous and needs to be awaited for completion.

Answer 5

Answer №3

Starting fresh with a brand new app in the beforeEach hook and only tearing it down in the afterAll hook could lead to memory leaks as hidden references may be preventing proper garbage collection. By assigning a new instance to the app variable, previous references may not be cleared properly - such as the reference obtained by the request function.

To prevent this, switch from using beforeEach to beforeAll and you should resolve any potential memory leaks.

Answer 6

Starting fresh with a brand new app in the beforeEach hook and only tearing it down in the afterAll hook could lead to memory leaks as hidden references may be preventing proper garbage collection. By assigning a new instance to the app variable, previous references may not be cleared properly - such as the reference obtained by the request function.

To prevent this, switch from using beforeEach to beforeAll and you should resolve any potential memory leaks.

Answer 7

Answer №4

If you're still facing errors even after closing the connection and it's an intermittent issue, consider including --no-cache --watchAll in your command. Here is the complete syntax to try:

"test": "jest --watchAll --no-cache --detectOpenHandles"

Answer 8

If you're still facing errors even after closing the connection and it's an intermittent issue, consider including --no-cache --watchAll in your command. Here is the complete syntax to try:

"test": "jest --watchAll --no-cache --detectOpenHandles"

Answer 9

Answer №5

I encountered a similar problem.

    "test:e2e": "jest --config ./test/jest-e2e.json --no-cache --detectOpenHandles",

This solution worked perfectly for me.

Answer 10

I encountered a similar problem.

    "test:e2e": "jest --config ./test/jest-e2e.json --no-cache --detectOpenHandles",

This solution worked perfectly for me.

Answer 11

Answer №6

In my case, I needed to disconnect from the server and the client of my databases.

afterAll(async () => {
 await server.disconnect();
 await databaseClient.close();
});

Answer 12

In my case, I needed to disconnect from the server and the client of my databases.

afterAll(async () => {
 await server.disconnect();
 await databaseClient.close();
});

Answer 13

Answer №7

Instead of using the variable it, consider replacing it with test and then passing done as a parameter to call it. I found this approach to be effective in my case.

test('mutation', async (done) => {
    const mutation = {
      query: `mutation Create($title: String!) {
        create(title: $title) {
          id,
          title
        }
      }`,
      variables: {
        title: 'Mon programme',
      },
    }
    const response = request(app.getHttpServer())
      .post('/graphql')
      .send(mutation)
     expect(response).to.be(HttpStatus.Ok)
     done()
  })

Answer 14

Instead of using the variable it, consider replacing it with test and then passing done as a parameter to call it. I found this approach to be effective in my case.

test('mutation', async (done) => {
    const mutation = {
      query: `mutation Create($title: String!) {
        create(title: $title) {
          id,
          title
        }
      }`,
      variables: {
        title: 'Mon programme',
      },
    }
    const response = request(app.getHttpServer())
      .post('/graphql')
      .send(mutation)
     expect(response).to.be(HttpStatus.Ok)
     done()
  })

Answer 15

Answer №8

// for every single test

it('the provided explanation', (done) => {
        request(app)
          .get('/some-path')
          .end(done);
  });

Answer 16

// for every single test

it('the provided explanation', (done) => {
        request(app)
          .get('/some-path')
          .end(done);
  });

Answer 17

Answer №9

Thanks Toomuchrice4u for the helpful answer. Their solution involved implementing a logout method within a service utilized by a component, which was then invoked within an afterEach block as shown below:

afterEach(async () => {

await userService.logout();

});

Answer 18

Thanks Toomuchrice4u for the helpful answer. Their solution involved implementing a logout method within a service utilized by a component, which was then invoked within an afterEach block as shown below:

afterEach(async () => {

await userService.logout();

});

Answer 19

Answer №10

Dealt with a mongoose issue before and resolved it by implementing process.exit() in my overall cleanup file.

Answer 20

Dealt with a mongoose issue before and resolved it by implementing process.exit() in my overall cleanup file.

Answer 21

Answer №11

Issue: TCPWRAP

I encountered a problem where I was closing the mongo connection in the global teardown section. However, in one of my test case files, I had defined functions and functionality related to mongo but never actually used them anywhere. Once I removed those unused declarations, the issue was resolved.

Answer 22

Issue: TCPWRAP

I encountered a problem where I was closing the mongo connection in the global teardown section. However, in one of my test case files, I had defined functions and functionality related to mongo but never actually used them anywhere. Once I removed those unused declarations, the issue was resolved.

Answer 23

Answer №12

Make sure to review your package.json file under the scripts section for the presence of the test:e2e command. If you see it, be sure to check the content and remove any instances of the parameter --detectOpenHandles. The script configuration should resemble:

"test:e2e": "jest --config ./test/jest-e2e.json --forceExit"

Answer 24

Make sure to review your package.json file under the scripts section for the presence of the test:e2e command. If you see it, be sure to check the content and remove any instances of the parameter --detectOpenHandles. The script configuration should resemble:

"test:e2e": "jest --config ./test/jest-e2e.json --forceExit"

Jest has identified a single open handle that may be preventing Jest from exiting: TCPSERVERWRAP

Answer №1

Answer №2

Answer №3

Answer №4

Answer №5

Answer №6

Answer №7

Answer №8

Answer №9

Answer №10

Answer №11

Answer №12

Similar questions

Installation and execution of TypeScript jQuery / Bootstrap definition file on a local machine using npm typings: A step-by-step guide

Accessing node_modules in TypeScript within an Asp.Net Core application

Error: The property 'process' cannot be read because it is not defined

The angular framework is unable to assign a value to the property 'xxxx' because it is currently undefined

Getting a specific array from the API with fetch in Angular: A step-by-step guide

Unable to create resource in nestjs due to typeScript compatibility issue

The 'Subscription' type does not contain the properties: source, operator, lift, subscribe, and three other properties that are present in the 'Observable<EnumValue[]>' type

Using a Class Decorator in Typescript to Enhance Static Methods across all Classes

Jest has encountered an error: TypeError - It is impossible to access the properties of an undefined object (specifically attempting to read '

Angular 5 internationalization now supports the ability to access translation strings from places other than just templates

Definition of type instantiation in TypeScript

When utilizing AngularFire with Firebase Firestore Database, users may encounter instances where data duplication occurs on

A step-by-step guide to configuring a middleware exclusively for a particular resolver within a Graphql backend utilizing Apollo Express

Precise object mapping with Redux and Typescript

TypeScript enum type encompassing all potential values

Ways to address the issue arising from the utilization of the "as" keyword

Guidelines for Managing Test Cases for a Promise-Returning Function with Resolve and Reject in Angular 6

Is there a potential issue in Next.js 14 when utilizing the "useClient" function alongside conditional rendering in the app/layout.tsx file?

Stop WebStorm from automatically importing code from a different Angular project within the same workspace

Error in Mongoose Schema Configuration Detected in NestJS App