improved-initiative icon indicating copy to clipboard operation
improved-initiative copied to clipboard

Lodash import reported as an open handle by jest --detectOpenHandles

Open cynicaloptimist opened this issue 6 years ago • 12 comments

Not sure how to troubleshoot this. When running jest the test runner succeeds, but reports

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.

Running jest --detectOpenHandles Encounter reports the following:

 PASS  client\test\Encounter.test.ts
  Encounter
    √ A new Encounter has no combatants (16ms)
    ○ skipped 3 tests

Test Suites: 1 passed, 1 total
Tests:       3 skipped, 1 passed, 4 total
Snapshots:   0 total
Time:        3.479s
Ran all test suites matching /Encounter/i.

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

  ●  PROMISE

    > 1 | import * as _ from "lodash";
        | ^
      2 |
      3 | export interface KeyValueSet<T> {
      4 |     [key: string]: T;

          at Function.resolve (<anonymous>)
      at runInContext (node_modules/lodash/lodash.js:6069:36)
      at Object.<anonymous> (node_modules/lodash/lodash.js:17078:11)
      at Object.<anonymous> (node_modules/lodash/lodash.js:17105:3)
      at Object.<anonymous> (common/Toolbox.ts:1:1)


  ●  PROMISE

          at Function.resolve (<anonymous>)
      at Object.<anonymous> (node_modules/lodash.reduce/index.js:1589:32)
      at Object.<anonymous> (node_modules/react-string-replace-recursively/lib/substituteHelper.js:5:14)

cynicaloptimist avatar Jun 10 '18 05:06 cynicaloptimist

I'm getting this issue as well :(

reggi avatar Jun 20 '18 11:06 reggi

These errors are kind of a bummer.

I may have a leak or some run-on process but I can't find it...

reggi avatar Jun 20 '18 22:06 reggi

I am having the same issue. Have you found any solution for this?

CrisTowi avatar Jun 27 '18 18:06 CrisTowi

I haven't figured this out, might be time to cross post this to StackOverflow.

cynicaloptimist avatar Jun 28 '18 05:06 cynicaloptimist

I had the same issue. I "fixed" the issue by importing individual lodash components instead of the entire lib.

robmcguinness avatar Jun 28 '18 15:06 robmcguinness

I'm having this issue in a completely separate repo. If you've figured this out, can you post a solution here or on StackOverflow?

anandnimkar avatar Jun 29 '18 02:06 anandnimkar

Same issue for me :s

prevostc avatar Jun 29 '18 13:06 prevostc

Importing individual lodash components works for Toolbox.ts, but Encounter.ts still warns:

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

  ●  PROMISE

      1 | import * as ko from "knockout";
    > 2 | import { max, sortBy } from "lodash";

cynicaloptimist avatar Jun 30 '18 19:06 cynicaloptimist

Got the same issue using nock :

●  PROMISE

      at Function.resolve (<anonymous>)
      at runInContext (node_modules/lodash/lodash.js:6069:36)
      at Object.<anonymous> (node_modules/lodash/lodash.js:17078:11)
      at Object.<anonymous> (node_modules/lodash/lodash.js:17105:3)
      at Object.<anonymous> (node_modules/nock/lib/common.js:3:9)

brunoMaurice avatar Jul 02 '18 07:07 brunoMaurice

I'm getting this issue across multiple versions of lodash, and the linked lines go to Promise.resolve() calls:

Errors from Jest

  ●  PROMISE

          at Function.resolve (<anonymous>)
      at Object.<anonymous> (node_modules/lodash.omitby/index.js:1576:32)

  ●  PROMISE

          at Function.resolve (<anonymous>)
      at runInContext (node_modules/private/dependency/node_modules/lodash/lodash.js:5975:36)

  ●  PROMISE

      1 | "use strict";
      2 | Object.defineProperty(exports, "__esModule", { value: true });
    > 3 | const _ = require("lodash");
        |           ^
      4 | const errors = require("./errors");
      5 | const codeToErrorMap = {};
      6 | for (const errorType of _.values(errors)) {

          at Function.resolve (<anonymous>)
      at runInContext (node_modules/lodash/lodash.js:6069:36)
      at Object.<anonymous> (node_modules/lodash/lodash.js:17078:11)
      at Object.<anonymous> (node_modules/lodash/lodash.js:17105:3)

Linked line from lodash

Both lodash lines resolve to this

     // Fallback for data views, maps, sets, and weak maps in IE 11 and promises in Node.js < 6.
     if ((DataView && getTag(new DataView(new ArrayBuffer(1))) != dataViewTag) ||
         (Map && getTag(new Map) != mapTag) ||
+        (Promise && getTag(Promise.resolve()) != promiseTag) ||
         (Set && getTag(new Set) != setTag) ||
         (WeakMap && getTag(new WeakMap) != weakMapTag)) {
       getTag = function(value) {
         var result = objectToString.call(value),
             Ctor = result == objectTag ? value.constructor : undefined,
             ctorString = Ctor ? toSource(Ctor) : undefined;

Open handles from wtfnode

[WTF Node?] open handles:
- File descriptors: (note: stdio always exists)
  - fd 1 (tty) (stdio)
  - fd 2 (tty) (stdio)
- Sockets:
  - 127.0.0.1:58344 -> 127.0.0.1:9050
    - Listeners:
      - connect: Object.<anonymous>.Connection.connect @ /Users/aturek/service/node_modules/pg/lib/connection.js:58
  - (?:?) -> localhost:? (destroyed)
- Timers:
  - (1000 ~ 1000 ms) (anonymous) @ /Users/aturek/service/node_modules/pg-pool/node_modules/generic-pool/lib/generic-pool.js:247
Unable to determine callsite for "Function". Did you require `wtfnode` at the top of your entry point?
  - (1000 ~ 1000 ms) (anonymous) @ unknown:0
Unable to determine callsite for "Function". Did you require `wtfnode` at the top of your entry point?
  - (100 ~ 100 ms) (anonymous) @ unknown:0

alexturek avatar Jul 03 '18 22:07 alexturek

Importing singular lodash libraries works for lodash, but what about other libraries :( ?

jdalrymple avatar Jul 04 '18 21:07 jdalrymple

I think this is a bug with jest, and I've filed an issue https://github.com/facebook/jest/issues/6639

alexturek avatar Jul 05 '18 21:07 alexturek