Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Having trouble running Jest, unhandled Promises #1015

Closed
ncrmro opened this issue Jul 26, 2018 · 13 comments
Closed

Having trouble running Jest, unhandled Promises #1015

ncrmro opened this issue Jul 26, 2018 · 13 comments

Comments

@ncrmro
Copy link

ncrmro commented Jul 26, 2018

Awesome project!

Have a database class that has public connect and close methods. Which Jest uses before and afterAll to cleanly connect and disconnect during tests.

Looks like Objection might still be running. Screen shot of code below. Any ideas on how to close this. Log shows

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

  ●  PROMISE

          at Function.resolve (<anonymous>)
      at Object.<anonymous> (node_modules/lodash/_getTag.js:37:32)
      at Object.<anonymous> (node_modules/lodash/_baseIsEqualDeep.js:5:14)


  ●  PROMISE

      at Object.getNativePromise (node_modules/bluebird/js/release/util.js:324:27)
      at Object.<anonymous> (node_modules/bluebird/js/release/schedule.js:7:26)
      at Object.<anonymous> (node_modules/bluebird/js/release/async.js:4:16)


  ●  PROMISE

          at Function.resolve (<anonymous>)
      at Object.<anonymous> (node_modules/objection/lib/utils/clone.js:1569:32)
      at Object.<anonymous> (node_modules/objection/lib/utils/clone.js:2303:3)
      at Object.<anonymous> (node_modules/objection/lib/utils/objectUtils.js:1:57)

dbjest

Code base can be found here

Thanks again for the awesome tool

@koskimas
Copy link
Collaborator

koskimas commented Jul 26, 2018

Objection doesn't hold on to any promises of run anything in the background. The problem is somewhere else I'm afraid.

@koskimas
Copy link
Collaborator

koskimas commented Jul 26, 2018

Are you creating multiple instances of the Database class simultaneously? You set the connection in each of them globally using Model.knex. Only the last one will be used in all of them. You can use this.model = Model.bindKnex(knex) to get a new instance for each of them.

@ncrmro
Copy link
Author

ncrmro commented Jul 26, 2018

@koskimas I am not creating multiple instances, atm it should just be a single sqlite memory instance.

@heisian
Copy link
Contributor

heisian commented Jul 26, 2018

@ncrmro You can't just call await this.knex.destroy(callback). It does not return a promise, it has a callback function, and needs to be promisified first:

const { promisify } = require('util')
const disconnect = promisify(this.knex.destroy)

(async() => {
  await this.knex.destroy()
})()

@heisian
Copy link
Contributor

heisian commented Jul 26, 2018

or, as I do in my jest suites:

await promisify(this.knex.destroy)()

@ncrmro
Copy link
Author

ncrmro commented Jul 26, 2018

@heisian this is very insightful been learning more and more about how async and promises work each day. Will let you guys know when/if resolved.

@heisian
Copy link
Contributor

heisian commented Jul 26, 2018

Actually I might be wrong - according to the knex docs:

If you ever need to explicitly teardown the connection pool, you may use knex.destroy([callback]). You may use knex.destroy by passing a callback, or by chaining as a promise, just not both.

Though I do know for a fact wrapping it in promisify works, since that's what I use in my own tests.

@ncrmro
Copy link
Author

ncrmro commented Jul 26, 2018

@heisian tried

await promisify(this.knex.destroy)()

No luck, do you have any example somewhere with knex, objection and jest working?

Maybe at least versions and snippits? Thinking maybe it's sqlite. I've t ried various combos of async/await and without. this.knex.destroy(cb) never fires the callback either. if I console.log(this.knex) it pops up. Might need to move to knex and reference issue here.

@ncrmro
Copy link
Author

ncrmro commented Jul 26, 2018

I do see somethings coming out of objection though?

          at Function.resolve (<anonymous>)
      at Object.<anonymous> (node_modules/objection/lib/utils/clone.js:1569:32)
      at Object.<anonymous> (node_modules/objection/lib/utils/clone.js:2303:3)
      at Object.<anonymous> (node_modules/objection/lib/utils/objectUtils.js:1:57)

@ncrmro
Copy link
Author

ncrmro commented Jul 26, 2018

Seeing this #534

@ncrmro
Copy link
Author

ncrmro commented Jul 26, 2018

cynicaloptimist/improved-initiative#250

Links to this

Using lodash causes "open handles" warnings
jestjs/jest#6639

@ncrmro
Copy link
Author

ncrmro commented Jul 26, 2018

Looks like bad timing apologies..

Stiill wonder about that lingering objection promise but we shall see.
jestjs/jest#6716

Going to just have the server started externally.

@excalios
Copy link

Hello,
Just curious on why this is happening? It's also with jest it only happens when objection is there. As ncrmro said #534 we need to explicitly close the connection. So on each test files I need to add an afterAll() function to close the connection. I don't really like this solution It's very repetitive on each file and jest globalTeardown doesn't work either.
image

Cruikshanks added a commit to DEFRA/water-abstraction-system that referenced this issue Sep 28, 2023
When trying to work with the DB in the tests we were getting

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

Googling led us to [Having trouble running Jest, unhandled Promises](Vincit/objection.js#1015) and [Need to explicit destroy knex in order to stop the script](Vincit/objection.js#534). The second issue included a comment that setting the pool min size to 0 and idleTimeoutMillis to 500 would solve the problem. We tried it and it worked!
Cruikshanks added a commit to DEFRA/water-abstraction-system that referenced this issue Sep 28, 2023
When trying to work with the DB in the tests we were getting

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

Googling led us to [Having trouble running Jest, unhandled Promises](Vincit/objection.js#1015) and [Need to explicit destroy knex in order to stop the script](Vincit/objection.js#534). The second issue included a comment that setting the pool min size to 0 and idleTimeoutMillis to 500 would solve the problem. We tried it and it worked!
Cruikshanks added a commit to DEFRA/water-abstraction-system that referenced this issue Oct 3, 2023
When trying to work with the DB in the tests we were getting

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

Googling led us to [Having trouble running Jest, unhandled Promises](Vincit/objection.js#1015) and [Need to explicit destroy knex in order to stop the script](Vincit/objection.js#534). The second issue included a comment that setting the pool min size to 0 and idleTimeoutMillis to 500 would solve the problem. We tried it and it worked!
Cruikshanks added a commit to DEFRA/water-abstraction-system that referenced this issue Oct 8, 2023
When trying to work with the DB in the tests we were getting

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

Googling led us to [Having trouble running Jest, unhandled Promises](Vincit/objection.js#1015) and [Need to explicit destroy knex in order to stop the script](Vincit/objection.js#534). The second issue included a comment that setting the pool min size to 0 and idleTimeoutMillis to 500 would solve the problem. We tried it and it worked!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants