6

I know this problem has been dealt with so many times, but none of them seem to solve the issue of reliably detecting dangling promises (even those that resolve properly).

So I want to be able to figure out a way (whether at runtime or better at static time) to root out "dangling promises", especially of this class:

async function a() {
    ... do some async operation ...
}
async function b() {
    a(); // forgot to call await on it
}

where I have accidentally forget to await on one function and some task that executes asynchronously doesn't get awaited on. Often times these types of bugs don't throw exceptions so I can't just use "unhandledRejection" and call it a day.

At this point after lots of desperate attempts I just need a way to detect this kinda faulty pattern at either (optimally) static/compile/lint time or at runtime. Runtime for me I think should work assuming I have good test coverage.

tl;dr basically, I'm searching for some code that would do something like the following:

Error: Potential dangling promise detected!
    ...
    at b (/dangling.js:5:3)

For each dangling promise

My thought process

I first tried finding some static analysis library that would help to detect these things (theoretically it should be possible but I had no luck with finding such a thing). A while back I remember finding something in the depths of stackoverflow that talked about using some typescript checker to check for dangling promises, though now I can't find it anymore :( . Though at the time changing the entire codebase to typescript was a no-go. (Later I learned you can actually use tsc to typecheck javascript (given that you do some type annotation in comments))

Currently I was previously using node version 11, so I thought about using the node.js's async_hooks API and try to listen on events (apparently simply monkey patching the Promise constructor wouldn't work because node.js bypasses the Promise constructor when creating a Promise object to return from an async function). Using node v11, after a bit of code hackery here it seemed to work (though it's not very efficient cause it throws away a lot of promise optimization in the v8 engine, but it does the job). There was a small hiccup in this entire operation in that I had to still monkey patch the then/catch/finally functions of the Promise API to check if we are currently calling that function (somehow that worked with detecting some dangling promises).

Now enter node v12 (apparently I need this for certain other things that are breaking), and now that hackery (unsurprisingly) completely breaks. After scrutinizing the version diffs, seems like they optimized the await/async implementation. After narrowing down the reason, it seems like await no longer calls the then function of the promise and just directly does some native shenanigans (idk what really).

Now I'm actually kinda desperate for some solution (and maybe if Typescript has some way of type-checking these dangling promises, what was the option to enable this check? I know (tested) that tsc doesn't do this by default).

Roamer-1888
  • 19,138
  • 5
  • 33
  • 44
theKidOfArcrania
  • 488
  • 4
  • 13
  • Can you not use an eslint plugin? E.G: https://www.npmjs.com/package/eslint-plugin-promise – Lekoaf Apr 24 '20 at 07:26
  • hmm interesting... i will look into that, thanks – theKidOfArcrania Apr 24 '20 at 07:27
  • 1
    TSLint contains a no-async-without-await rule that would work for this case: https://palantir.github.io/tslint/rules/no-async-without-await/ – David Federspiel Apr 24 '20 at 07:28
  • @DavidFederspiel - But not in the case where that's just one call of several, and at least one of the others has `await`. – T.J. Crowder Apr 24 '20 at 07:28
  • @Lekoaf - Does that plugin support detecting this situation? Doing so requires type information... – T.J. Crowder Apr 24 '20 at 07:29
  • 1
    @ theKidOfArcrania - As you've noted, doing this requires an analysis tool of some kind, ideally one with type information. [`typescript-eslint`](https://github.com/typescript-eslint/typescript-eslint) is one such tool, the successor to TSLint. It works with TypeScript. I don't *think* it has a rule that does what you want, but it should be possible to write a plugin for one, since it does have type information and so you can check that a function returns a promise and check whether it's being `await`ed. Edge cases may be tricky, for instance passing an `async` function into `map` to build... – T.J. Crowder Apr 24 '20 at 07:32
  • I just did a quick Googling of eslint plugins. But I'm sure you can find one that fits your needs. – Lekoaf Apr 24 '20 at 07:32
  • ...an array of promises to use `Promise.all` on is still a valid and appropriate idiom in an `async` function (when you want things running in parallel), but it should be possible to reliably at least handle your literal example -- a function call where nothing uses its return value at all. – T.J. Crowder Apr 24 '20 at 07:33
  • @Lekoaf yeah I don't think the eslint-plugin-promise quite works for me, because I think definitely this does require some type inference/information, and that plugin apparently misses async functions. – theKidOfArcrania Apr 24 '20 at 07:44
  • 1
    In order to solve the issue of detecting *dangling promises*, you will first need to solve the issue of detecting *promises*, which is itself no mean feat given that any Function can return Promise, not just AsyncFunctions. – Roamer-1888 Apr 24 '20 at 08:03
  • You would also need to cater for cases where `await` is intentionally omitted, eg where `.then() syntax is used (rightly or wrongly), or keyword `return` is present instead of `await`. – Roamer-1888 Apr 24 '20 at 08:11
  • yeah I think there is a plugin for tslint/eslint-typescript that does that: no-floating-promises, but it apparently mandates only typescript files – theKidOfArcrania Apr 24 '20 at 08:17
  • Out of curiosity, why is this such a big issue in the first place? Are you trying to prevent yourself form making this mistake or are you trying to catch other devs doing it? – timotgl Apr 24 '20 at 08:25
  • mostly trying to prevent myself from this error :) – theKidOfArcrania Apr 24 '20 at 08:27

1 Answers1

1

You are most likely looking for the no-floating-promises rule of typescript-eslint

Bergi
  • 630,263
  • 148
  • 957
  • 1,375