--detectOpenHandles reports open handles in ZLIB, but exits cleanly

[oliversalzburg]

🐛 Bug Report

While investigating a different issue in Jest, I ran my test suite with --detectOpenHandles, even though the test suite exits cleanly, without workers needing to be force exited.

When doing so, Jest reports several open handles in relation to ZLIB. The printed stack traces look like:

  ●  ZLIB

      25161 |           });
      25162 |         } else {
    > 25163 |           const decompressedData = external_zlib_default().inflateRawSync(data);
            |                                                            ^
      25164 |           this.fileSources.set(index, decompressedData);
      25165 |           return decompressedData;
      25166 |         }

      at ZipFS.getFileSource (.pnp.cjs:25163:60)
      at ZipFS.readFileBuffer (.pnp.cjs:25483:17)
      at ZipFS.readFileSync (.pnp.cjs:25469:23)
      at .pnp.cjs:26366:20
      at .pnp.cjs:26494:58
      at ZipOpenFS.getZipSync (.pnp.cjs:26639:14)
      at ZipOpenFS.makeCallSync (.pnp.cjs:26494:17)
      at ZipOpenFS.readFileSync (.pnp.cjs:26354:17)
      at VirtualFS.readFileSync (.pnp.cjs:23714:26)
      at PosixFS.readFileSync (.pnp.cjs:23714:26)
      at URLFS.readFileSync (.pnp.cjs:23714:26)
      at Object.<anonymous> (.yarn/__virtual__/@mikro-orm-core-virtual-9ce4c28b96/0/cache/@mikro-orm-core-npm-4.5.5-4d65c94f1b-fe27d61d2a.zip/node_modules/@mikro-orm/core/types/index.js:14:14)
      at Object.<anonymous> (.yarn/__virtual__/@mikro-orm-core-virtual-9ce4c28b96/0/cache/@mikro-orm-core-npm-4.5.5-4d65c94f1b-fe27d61d2a.zip/node_modules/@mikro-orm/core/utils/QueryHelper.js:7:17)
      at Object.<anonymous> (.yarn/__virtual__/@mikro-orm-core-virtual-9ce4c28b96/0/cache/@mikro-orm-core-npm-4.5.5-4d65c94f1b-fe27d61d2a.zip/node_modules/@mikro-orm/core/utils/index.js:19:14)
      at Object.<anonymous> (.yarn/__virtual__/@mikro-orm-core-virtual-9ce4c28b96/0/cache/@mikro-orm-core-npm-4.5.5-4d65c94f1b-fe27d61d2a.zip/node_modules/@mikro-orm/core/typings.js:5:17)
      at Object.<anonymous> (.yarn/__virtual__/@mikro-orm-core-virtual-9ce4c28b96/0/cache/@mikro-orm-core-npm-4.5.5-4d65c94f1b-fe27d61d2a.zip/node_modules/@mikro-orm/core/index.js:19:17)
      at Object.<anonymous> (packages/core-models3/source/index.ts:1:1)
      at Object.<anonymous> (packages/core-models3/source/arguments/PageArguments.ts:1:1)
      at Object.<anonymous> (packages/core-models3/source/arguments/PageArguments.test.ts:4:1)

All stack traces point to invokation of inflateRawSync().

To Reproduce

I have no repro case, as I'm hoping this is fairly obvious to a developer. I can probably create one if required.

Expected behavior

I'm currently assuming this to be a false positive that shouldn't be reported.

Link to repl or repo (highly encouraged)

envinfo

  System:
    OS: Linux 5.4 Ubuntu 20.04.2 LTS (Focal Fossa)
    CPU: (12) x64 Intel(R) Core(TM) i7-6850K CPU @ 3.60GHz
  Binaries:
    Node: 14.17.0 - /usr/bin/node
    Yarn: 3.0.0-rc.5 - ~/.yarn/bin/yarn
    npm: 6.14.7 - ~/.npm-global/bin/npm

[sdro]

We have a similar issue, but it only occurs in relation with mongodb-memory-server:

import { MongoMemoryServer } from 'mongodb-memory-server';
import { createInflate } from 'zlib';

createInflate();

describe('Example', () => {
  test('Example', async () => {
    const mongoServer = await MongoMemoryServer.create();

    expect(true);
    await mongoServer.stop();
  });
});

Output:

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

  ●  ZLIB

      2 | import { createInflate } from 'zlib';
      3 |
    > 4 | createInflate();
        |              ^
      5 |
      6 | describe('Example', () => {
      7 |   test('Example', async () => {

Without the mongo related code, jest does not report the open handle.

[SimenB]

PR welcome! Sounds like it should be added to the exceptions here: https://github.com/facebook/jest/blob/10d9580edec4058ffd8a7c52786331379e32e711/packages/jest-core/src/collectHandles.ts#L65-L77

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