Hacker News Reader

> - Promise.allSettled. THIS is useful. I've implemented this (under a different name) in almost every code base I've worked on, and got bit HARD by not understanding this behavior long ago (huge production outage that took hours and many engineers to discover)

You and your team didn't understand how Promise.allSettled behaved?

View on HN

No, Promise.allSettled didn't exist yet. It was Promise.all.

Someone basically made the assumption that await Promise.all would wait until ALL promises finished. Which is true..... unless one of them throws. In which case it continues. This caused a race condition. It was an extremely complex code base with 100s of engineers and the error very rarely happened, and when it did happen the app would get stuck on a loading screen forever. Also, it turns out "rarely" happens to a lot of people when you have millions of users.

I'm guessing the more common error, which I've definitely hit years ago, is not knowing that Promise.all returns immediately if any of the included promises reject.

Correct. It was millions of lines of code in a huge code base at a giant enterprise company with 100s of engineers. Somewhere buried in there there was a Promise.all that someone assumed would finish ALL of the promises, and didn't account for the fact that it bails on the first error.

That's what I'm guessing, too.

Reply on news.ycombinator.com