Elegant way to check if a Promise is pending

Intro

There's no solid way to check if a Promise is pending or finished, at least not in Node.js, so I wrote this simple snippet back in few months ago while I was searching for a simple way. I couldn't' find anything with one line max that will check the state of a promise so I came up with this simple solution. I have posted this solution on StackOverflow too. It's nothing special just an elegant & hacky way but works flawlessly on every Node.js version from 8~14. It's not stable though and the rational solution here should be a native method inside V8's core to check if a promise is pending or not.

The trick

If we take the whole object of a promise and inspect it using the inspect method from the native libraries of Node.js, we will get either 'Promise { <pending> }' while pending or 'Promise { undefined }' when finished.
Now if we check the string for the word pending we could define the state and check if a promise is pending or not using the following one line: util.inspect(myPromise).includes("pending").

Here's an example to get you started:

const util = require("util")

function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

(async ()=>{
  let letmesleep = sleep(13000)
  setInterval(()=>{
    console.log(util.inspect(letmesleep).includes("pending"))
  },1000)
})()

Result

true
true
false
false
false

Support

If you liked this article please follow me on Twitter :)
https://twitter.com/devcrafter91

Comments

[Basti Ortiz]

I mean this is cool and all, but I'm not really sure when one would ever want to know when a promise is "pending".

It's a fun experiment for the sake of learning, but usually, one would be better off just waiting until the Promise#then handler is fired.

However, if it is indeed "necessary" to do so (though I highly doubt that there is no better approach), you can use the Promise#then handler to achieve it more "elegantly" and concisely without the use of Node's meta tools.

let isPending = true;
Promise.resolve(1)
  .then(() => { isPending = false; });

[Drakos]

If you're dealing with a scenario where you have a lot of promises and you wanted to just check the state for reporting or something, you must then define a bunch of variables for every promise which is ugly imho.

[CallMeLaNN]

Checkout something like this, yeah, everything is just the Promise#then.

I never thought to check the "pending" even in a complex scenario. It is not something I wanted to grab and go, I'll come back later. Maybe you need it if you deal with coroutine or infinite loop but JS don't need that and I never done that on function generator too since there are always a way:

Since we can keep promise instance around, we can always append more or chain Promise#then to structure the flow we want.

[Basti Ortiz]

In that case, assuming a Node environment as in your example in the article, wouldn't it be better (and more readable) to implement an event emitter instead?

It seems to me that promises may be the wrong abstraction for the job.

[Jakob Rosenberg]

Promise.all is great if you're working with a static array, but what if your array is dynamic? Promises added between the wait and the resolve will then be ignored.

To solve that you could do something like

/**
 * @param {Promise<any>[]} promises
 */
const dynamicPromiseAll = async (promises) => {
  const result = await Promise.all(promises);
  const hasPending = promises.map((promise) => util.inspect(promise).includes("pending")).filter(Boolean).length;
  return hasPending ? dynamicPromiseAll(promises) : result;
};

[SamwiseLA]

Just wanted to thank you.

This is all I needed.

Why? I am doing an animation in VR and the Avatar triggers the animation AND I do not want it retriggered until it ends. Like an elevator ride that I do not want interrupted. This worked great! If you're ever in ASVR (AltSpaceVR) come and check out what I'm talking about. Like, a Hot Air Balloon Rise...

[CallMeLaNN]

I'm not sure if I understand correctly, but maybe you not using Promise in a way you imagine the outcome.

If you chain the promises (to put observe it in the middle of the chain) the original consumer of the final promise in the chain doesn't affected as long as you pass the resolve value around.

If you append more .then() to the original promise, you can get notified and the consumer of the promise unaffected.

It doesn't affect the performance or lag unless you add sync I/O, it is just code structure. I believe there will be an extra tiny processing of inspect above then using plain Promise#then

[Marc Jovaní González]

Thank you very much. Indeed, very elegant (I wasn't entirely sure when I clicked on my Google result).

I'm testing a semaphore that works with promises, and I was just interested in knowing if the state of a variable is a resolved or pending promise.

I didn't want to add timeouts to my tests. And your solution worked amazingly well. Thank you very much Drakos.