ladjs / supertest

🕷 Super-agent driven library for testing node.js HTTP servers using a fluent API. Maintained for @forwardemail, @ladjs, @spamscanner, @breejs, @cabinjs, and @lassjs.
MIT License
13.75k stars 758 forks source link

open handles with body-parser#1.20.0 #772

Open lucamartini opened 2 years ago

lucamartini commented 2 years ago

Hallo,

jest test run does not exit and instead prints this error

Jest has detected the following 64 open handles potentially keeping Jest from exiting:
  ●  bound-anonymous-fn
      23 |
      24 |   const response = await request
    > 25 |     .post('/gql')
         |      ^
      26 |     .set('origin', config.devHosts[0])
      27 |     .send(loginQuery)
      28 |     .expect(200);
      at Test.serverAddress (node_modules/supertest/lib/test.js:48:35)
      at new Test (node_modules/supertest/lib/test.js:34:14)
      at Object.post (node_modules/supertest/index.js:28:14)
      at login (test/integration/helpers/login.js:25:6)
      at Object.<anonymous> (test/integration/users/usersMutations.itest.js:45:25)
          at runMicrotasks (<anonymous>)
...

We have found this happens only for the routes where we use the express body-parser middleware. express version = 4.17.3 body-parser version = 1.20.0

zachsitka commented 2 years ago

I am also seeing this.

Jest has detected the following 1 open handle potentially keeping Jest from exiting:

  ●  TCPSERVERWRAP

      24 |       request(app)
    > 25 |           .get('/')
         |            ^
      26 |           .query({/*query data*/})
      27 |           .send()
      28 |           .expect('Location', '/error.html');

      at Test.serverAddress (node_modules/supertest/lib/test.js:48:35)
      at new Test (node_modules/supertest/lib/test.js:34:14)
      at Object.obj.<computed> [as get] (node_modules/supertest/index.js:28:14)
      at Object.<anonymous> (functions/src/express-apps/oauth-callback.spec.ts:25:12)

express = 4.17.3 supertest = 6.2.2

ricardomat commented 2 years ago

I'm having the same lucamartini's problem, and I'm using express 4.17.3, supertest 6.2.2 and body-parser version = 1.20.0. It seems to started recently, as I'm upgrading my projects, because I had the tests for quite a while, and just recently this problems appeared. When I put a timeout in afterAll method, depending on how long I wait, the problem do not happen.

wilhelm-lynch commented 2 years ago

@lucamartini and @ricardomat are you using a fake database? I had the same problem and then by doing my research, I have found a beautiful solution which is using the NPM package mongodb-memory-server This should be installed as development dependency!!!

bscantor23 commented 2 years ago

Hello! As a plus comment, this also happens when using morgan

DanielFredriksson commented 2 years ago

Having the same problem

dominikwinter commented 2 years ago

It seems yarn add -D body-parser@^2.0.0-beta.1 fixes the problem ..

sshevlyagin commented 2 years ago

I ran into this as well, don't feel great running beta in prod though. Other ideas? :D Is this a known issue on the body-parser side?

kdupont-asfotec commented 2 years ago

Having the same problem

saqib-ahmed commented 2 years ago

Having the same problem. Can confirm that npm i -D body-parser@^2.0.0-beta.1 works for me.

branberry commented 2 years ago

Have the same problem as well, but upgrading body-parser to 2.0.0-beta.1 did not work for me.

omerlewitz commented 2 years ago

@saqib-ahmed fixed the problem in my case..

thisdotEric commented 2 years ago

Can confirm that this also worked on my setup.

"body-parser": "^2.0.0-beta.1",
"jest": "^28.1.3",
"supertest": "^6.2.4",
"typescript": "^4.7.4"
"express": "^4.18.1"

I had to use body-parser package as follow:

app.use(bodyParser.json());

Just want to mention that using body-parser as such without the code above

app.use(bodyParser.urlencoded({ extended: true /**or false */ }));

will result to these errors.

Jest has detected the following 3 open handles potentially keeping Jest from exiting:

  ●  write

      17 |
      18 |         const { statusCode } = await supertest(server)
    > 19 |           .post('/users')
         |            ^
      20 |           .send(userInput);
      21 |
      22 |         expect(statusCode).toBe(200);
Nicopa commented 1 year ago

^2.0.0-beta.1 It worked for me too.

mohamedelbalshy commented 1 year ago

I have the same issue

Jest has detected the following 2 open handles potentially keeping Jest from exiting:

  ●  bound-anonymous-fn

      332 |
      333 |         const response = await agent
    > 334 |             .post(routePath)
          |              ^
      335 |             .set({authorization: token})
      336 |             .send(requestBody);
      337 |

      at Test.serverAddress (node_modules/supertest/lib/test.js:48:35)
      at new Test (node_modules/supertest/lib/test.js:34:14)
      at TestAgent.<computed> [as post] (node_modules/supertest/lib/agent.js:62:17)
      at Object.post (src/files/tests/files.v1.test.js:334:14)
          at runMicrotasks (<anonymous>)

  ●  bound-anonymous-fn

      386 |
      387 |             const response = await agent
    > 388 |                 .post(routePath)
          |                  ^
      389 |                 .set({authorization: token})
      390 |                 .send(requestBody);
      391 |

      at Test.serverAddress (node_modules/supertest/lib/test.js:48:35)
      at new Test (node_modules/supertest/lib/test.js:34:14)
      at TestAgent.<computed> [as post] (node_modules/supertest/lib/agent.js:62:17)
      at Object.post (src/files/tests/files.v1.test.js:388:18)
          at runMicrotasks (<anonymous>)

Done in 8.99s.
huynq-2493 commented 1 year ago

upgrade to jest@29.2.1 and ts-jest@29.0.3 resolved it for me.

ryami333 commented 1 year ago

upgrade to jest@29.2.1 and ts-jest@29.0.3 resolved it for me.

You do not need to use ts-jest to reproduce this issue, so that's irrellevant. Upgrading to jest@29.2.1 does not fix the issue for me, which makes sense because Jest is not the cause of the issue. In fact, you do not even need to Supertest to reproduce this issue, the issue is somewhere in Express internals (perhaps body-parser as others have mentioned).

TL;DR we're all barking up the wrong tree here. This is a problem that Express' maintainers (who are not very active) need to solve.