DEV Community

The dangers of async/await

Christopher Kade on January 16, 2020

After a few months consulting on the rewriting of a large-scale application, I've come to realize that async/await was used de facto for most async...

Read full post

Lucis • Jan 16 '20

async/await are (almost) syntatic sugar for the plain-old Promise API, you could accomplish the same "blocking" behaviour using promise1().then(promise2).then(promise3) and so on, thus this is not a problem with async/await syntax per-se, IMO.

One using await should first know about the Promise API, so it'll know better how to use it

Christopher Kade • Jan 16 '20

Absolutely, and even when knowing these tools some developers tend not to prioritize parallel executions for some reason. A colleague said the same thing as you after reading it, and it's very pertinent.

Thanks Luciano !

Lucis • Jan 16 '20

I would suggest you to write a post of "How to parallelize your work with async/await". There's a nice feature that is something like:

const p1 = promise1()
const p2 = promise2()
const r1 = await p1
const r2 = await p2

If I'm not mistaken, this way you 1) use async/await, what's really nice 2) let the promises run right-away

Lawrence tranter • Jan 19 '20

Promise chains are a problematic solution, as each '.then' produces another promise. What happens if an earlier 'then' throws and there's no catch or other error handling? Memory leak

Lawrence tranter • Aug 23 '23

Welp. JS got us on this one. The new using keyword allows for simpler handling of cleanup if there was an error that would cause memory leaks otherwise.

Jean-Michel 🕵🏻‍♂️ Fayard • Jan 16 '20

well the trade-off here is that by using parallelism, you will probably spend more time coding and debugging your code.
I think it's fine to do the simple thing by default and parallelize only when you have measured that it's worth it

Christopher Kade • Jan 16 '20

Agreed, to some extent. If you have a clear way of determining which query failed and why, it shouldn't be taking you more time to debug whenever one of them throws an error.

As you said, it must be a calculated risk.

Jean-Michel 🕵🏻‍♂️ Fayard • Jan 16 '20

It depends, if you have two http queries that are totally independant OK, but if you have a number of asynchronous calls that do side effects, it's much harder to reason about it if you add parallelism

Christopher Kade • Jan 16 '20

That's a good point yeah, it can make it much harder to determine the cause of everything falling apart. It really should be done in the right circumstances.

Maxime Moreau • Jan 16 '20

Async with side effects is my nightmare :(

Matthis Duclos • Jan 16 '20

I think your article points out the fact we need to parallelize calls that don't depend on each other. I already read some code using promises that could have been parallelized too.

One of the advantages about async/await (outside the fact that the code may be easier to read) is that it can improve stacktraces. To know more about this point, I encourage you to read this blog post from Mathias Bynens

Matt Eland • Jan 16 '20

This is kind of funny. I was planning on writing an article this evening with something pretty close to this title, but focused on C# code.

Different points, but... still, I'll have to rethink that or at least the title.

Christopher Kade • Jan 16 '20

I'd love to read your take on it either way :) sorry for beating you to it haha

Rolf Streefkerk • Jan 17 '20

The title is just a bit misleading, it's more a discussion about parellelism vs serial execution.
I agree, if you don't take the program flow into account you can horribly increase application latency.
Good post

Zane Milakovic • Jan 16 '20

What a great write up. This is super valid code smell. I forget about this a lot when I am writing code with asynchronous/await first pass.

But when I do promises, I typically don’t. I never tried the promise with async/await like that. It’s clever and I am going to use it. Well done!

Christopher Kade • Jan 16 '20

Absolutely, thanks for catching my mistake. Must have made it while pasting my notes !

Alex Nudelman • Mar 11 '20

Absolutely! But there is a problem. If one of those will fail it will break all promise.all() iteration and you will be thrown into the catch. So I if you need/want to run fully async and parallel and get all results (errors and values) regardless of the failures you should use this:

 const promiseAllWithAllErrors = function(mapAsync) {
  return Promise.all(
    mapAsync.map(f =>
      f.then(r => Promise.resolve(r)).catch(e => Promise.resolve(new Error(e)))
    )
  )
}


promiseAllWithAllErrors([
   this.getConfig(),
    this.getUser(),
    this.checkRussianContext(query)
])

let's test it with some timeout function

const fun = function(txt) {
  return new Promise((yes, no) => {
    setTimeout(function() {
      if (txt === '2' || txt === '3') {
        no(txt + ' error')
      } else {
        yes(txt)
      }
    }, 5000)
  })
}

 promiseAllWithAllErrors([
  fun('1'),
  fun('2'),
  fun('3'),
  fun('4')
]).then(console.log)

output:

time node /tmp/t.js 
[ '1', Error: 2 error, Error: 3 error, '4' ]

real    0m5.205s.    ==> only 5 sec , instead of 5*4 and all answers in one array without interuptions  
user    0m0.071s
sys     0m0.044s

Lars Gyrup Brink Nielsen • Jan 16 '20

The most overlooked caveat of async-await is that we have to wrap it in a try-catch block to handle errors by catching rejected promises.

Thibault Maekelbergh • Jan 17 '20

I don't see why this would be considered a caveat? Thenable promises also need to explicitly declare a Promise#catch() to handle errors? What makes it different from wrapping async/await in try-catch?

Lars Gyrup Brink Nielsen • Jan 17 '20

I mean it's something to be aware of and it's often overlooked and not mentioned at all in articles discussing and guiding on async-await.

The difference between this and promises is that catch callbacks can be put specifically in any place in a promise chain. Of course, we can also do this with try-catch around a single statement, but that gets ugly pretty fast, especially if we want to keep the same variable scope between related try-catch blocks.

Yawar Amin • Jan 17 '20

Christopher, great and timely reminder of the danger of async. However I may be missing something but, about your last example:

Although this snippet poses a problem, did you spot it? ... Poor little initBooking will have to wait for both getBasket and fetchOptions to finish before executing even though it has nothing to do with the data they'll fetch.

None of these calls are fetching any data, at least in the code as shown. They can all be run in parallel with Promise.all...

Christopher Kade • Jan 17 '20

None of these calls are fetching any data

It's an example, the methods in question could be fetching data.

For example getBasket could fill the store's basket state variable needed by fetchOptions. I simply wasn't going to show the contents of these methods as they don't seem relevant to the point I'm making.

Thank you for your feedback Yawar !

Mesaque Francisco • Jan 16 '20

First of all, thanks for the article. I really enjoyed it, but something is bugging me, though.

When you say that "unrelated code shouldn't wait...", I think that there is something we're not addressing here, which is:

Unrelated code shouldn't be in the same function.

My approach on that would be:

1 - Split each block of unrelated code into its own async function. That will keep scope smaller and easy to keep track of what is happening at that moment.
2 - The main function would end up being a point where each step (each block of unrelated code) of the process are invoked in a meaningful order.

Christopher Kade • Jan 16 '20

Of course, but we must take into account use-cases where our code is running inside a hook for example (mounted, created etc.), or when dealing with legacy code.

The right thing to do would be refactoring it to fit what you mentioned, but we don't always have that option.

Jason Aunkst • Jun 23 '20

async/await is more often used when it should not be.

The async/await control flow is an abomination to me. I already have beef with Promises, and async/await just takes it to far.

I have fixed too many bugs in other people's code because they do not want to deal with async programming and instead just try to async-await their way through a feature.

Observables > Promises > Async/Await

Gábor Soós • Jan 16 '20

Why do you put await inside Promise.all array? It is not needed.

Christopher Kade • Jan 16 '20

Great catch, I must have made a mistake while pasting from my notes. Thanks!

Mariano • Jan 17 '20

The "danger" which you are referring is not a async/await thing. No matter which language/framework you are using, it doesn't make any sense to execute sequentially independent api calls. This applies to Java, nodejs, C or whatever language we are talking.

Yevhenii Herasymchuk • Jan 16 '20

Here, the first 3 requests are executed in parallel, whereas the next ones rely on data fetched beforehand and will therefore be executed afterwards. Although this snippet poses a problem, did you spot it?

Poor little initBooking will have to wait for both getBasket and fetchOptions to finish before executing even though it has nothing to do with the data they'll fetch.

I didn't get the message the author wanted to bring in Unrelated code should not have to wait section. That's exactly why async/await is cool and for sure not danger.

If you want to run them in parallel - you're going with Promise.all ( of course, knowing about the first-fail behavior), you may operate each call separately as well with a personal error handling.
Don't want to say anything bad, just didn't get the info from the section

Christopher Kade • Jan 16 '20

If you want to run them in parallel - you're going with Promise.all

Absolutely, if it's a habit you've developed as a developer. The point of this article being to help some beginners catch these sections that could be helped with something like Promise.all.

The example with initBooking is my abstract way of showing a bad use of a single awaited method.

Yevhenii Herasymchuk • Jan 16 '20

Agree, Christopher, thanks for the work. Actually benchmarks are awesome!
Just the title "dangers" makes it quite judging without actual arguments :)
P.S. You know how to make clickbait titles

Christopher Kade • Jan 16 '20

I love to spook my readers first and then relieve them when they understand that it's not that big of a deal haha.

Maybe the word side-effect would have been more interesting in this case. As in the side-effect of over-using this feature.

Alex Nudelman • Mar 11 '20 • Edited

yea but it still in implementation progress, kinda experimental.

developer.mozilla.org/en-US/docs/W...

Jochem Stoel • Jan 19 '20

Hey this was pretty interesting.

aRtoo • Jan 16 '20

I agree with this. Even nodejs has it on their guide.

leob • Jan 16 '20

Great points, it's all too easy to forget that async/await is just syntactic sugar on top of promises but still the same semantics under the hood.

Aditya Thebe • Jan 20 '20

This post is basically explaining how async/await works. Anyone with basic knowledge of async/await knows this. The title just seems like a clickbait to me.

Christopher Kade • Jan 20 '20

That's not a fair statement. I've tried to show good practices and how to avoid certain code smells based on previous experiences.
Sorry you feel that way.

Mikael • Jan 16 '20

When I started webdev I had a tendency to make sure everything was loaded before starting to display things. A few years later I took a look at my code, horrified..