1) What version of bluebird is the issue happening on?
3.5.0
2) What platform and version? (For example Node.js 0.12 or Google Chrome 32)
Node.js 8.11.1
3) Did this issue happen with earlier version of bluebird?
Unknown
I have been writing Jest tests for some code that uses the Mongoose ORM for MongoDB. This setup appears to delegate down to a lib called mquery, which then calls bluebird.
My tests pass, however, the test runner is prevented from exiting due to an unresolved Promise. Jest then recommended that I rerun my tests with the --detectOpenHandles flag, which is intended to debug this type of issue.
When running my tests with this flag enabled, it identified the following:
Jest has detected the following 1 open handle potentially keeping Jest from exiting:
● PROMISE
at Object.getNativePromise (../../node_modules/mquery/node_modules/bluebird/js/release/util.js:323:27)
at Object.<anonymous> (../../node_modules/mquery/node_modules/bluebird/js/release/schedule.js:7:26)
at Object.<anonymous> (../../node_modules/mquery/node_modules/bluebird/js/release/async.js:4:16)
It appears that the mquery library delegates down to bluebird and the following code causes an unresolved Promise to occur:
function getNativePromise() {
if (typeof Promise === "function") {
try {
var promise = new Promise(function(){});
if ({}.toString.call(promise) === "[object Promise]") {
return Promise;
}
} catch (e) {}
}
}
I have been having to force exit my process for now, but was hoping there would be a better approach.
getNativePromise _explicitly_ creates a promise that never resolves here.
On the other hand it shouldn't create any open handles or stop a test from exiting which you can easily verify by calling new Promise(() => {}) and verifying that the Node process does exit.
What Jest is actually doing is using native promises async hooks in order to determine open handles. This is a mistake on jest's end and isn't something we can fix anyway (since this is with native promises).
We are significantly changing promise async_hooks in Node anyway - Your princess is in another castle - sorry :(
Pinging @SimenB who I know from Jest to see what's the right course of action here - I think opening an issue against Jest is probably in order and I will also bring this up internally in the next promises-debugging Node team meeting.
Hiya! Basically a dupe of https://github.com/facebook/jest/issues/6639
I think the fix on Jest's side should be to ignore promises - promises don't keep the process open, so they are never the cause. The feature is made to detect stuff like running servers or database connections, and they are mostly tcp or dns type, never promises
Awesome, thanks for the quick response. I'll track the issue in Jest. 👍
Most helpful comment
Hiya! Basically a dupe of https://github.com/facebook/jest/issues/6639
I think the fix on Jest's side should be to ignore promises - promises don't keep the process open, so they are never the cause. The feature is made to detect stuff like running servers or database connections, and they are mostly tcp or dns type, never promises