Javascript – Unhandled Promise rejection despite common understanding

How a host deals with an unhandled promise rejection is implementation dependent. The ECMAScript specification says about this:

HostPromiseRejectionTracker is called in two scenarios:

1. When a promise is rejected without any handlers, it is called with its operation argument set to "reject".
2. When a handler is added to a rejected promise for the first time, it is called with its operation argument set to "handle".

A typical implementation of HostPromiseRejectionTracker might try to notify developers of unhandled rejections, while also being careful to notify them if such previous notifications are later invalidated by new handlers being attached.

I note that in NodeJs, this handler stops the script and does not allow the program to continue, and so the second iteration of the loop never occurs. In Chrome/Edge however, the console first shows an uncaught promise rejection error, but the asynchronous code can continue, and as soon as the promise rejections get handled, these error messages are removed from the console. These are clearly two different approaches to something that the ECMAScript specification has no say on: it is up to the host to decide what to do.

As to your analysis:

Here, despite common understanding that the promises […] would "really" start to execute only after Promise.all call.

It is not the promises that start executing. Promises are just objects, not functions. However, the setTimeout timers have started at the moment the promises were created, i.e. before the second loop. The effect of Promise.all is not that some promise gets "executed", but that a new promise is created which is guaranteed to resolve when all the given promises resolve, or will reject as soon as one of those rejects. So it has placed handlers on those promises, and the try ... catch block acts as a rejection handler for the new "all" promise.

What really opens the door to state changes, is the await. This will make the async function return. When the callstack is empty, the task queues will be monitored. When a setTimeout expires, a task will appear there, and that task will run your code to resolve/reject a promise.

If this is a rejection, and that promise has not yet received a rejection handler, it is expected that an uncaught promise rejection error will be triggered. Since the await in the first iteration of the loop only placed handlers on the "a" promises, the rejection of a "b" promise will lead to the uncaught rejection handler error. This is expected. Only when all "a" promises have resolved and the loop can make its second iteration, will there be a rejection handler set up for the "b" promises. Nodejs does not allow this to happen (at least not in the version I ran — v20), as it already interrupted the program when a "b" promise rejected.

You should not delay to attach rejection handlers on promises. The best moment to do that is when the promises are created, and certainly not after an await on another, unrelated promise.

Alternative implementation

If you intended to do as the console.log statements suggest, i.e. creating the promises by group, one group after the other, then don’t create groups of promises, but of tasks. With the latter I mean functions that — when executed — will create the promises. Now it makes sense to tackle the tasks by group: first execute them, await their promises, then continue and execute the next group of tasks, …etc.

Here is how that would look:

const waitResolve = (ms) => new Promise((resolve) => {
  setTimeout(() => {
    console.log(`Waited to resolve for ${ms}ms`);
    resolve(ms);
  }, ms);
});

const waitReject = (ms) => new Promise((resolve, reject) => {
  setTimeout(() => {
    console.log(`Waited to reject for ${ms}ms`);
    reject(ms);
  }, ms);
});

const run = async() => {
  const tasks = {
    a: [],
    b: [],
    c: [],
  };

  for (let i = 0; i < 5; i += 1) {
    tasks.a.push(() => waitResolve(1e4)); // Note the callback!
    tasks.b.push(() => waitReject(1e3));
    tasks.c.push(() => waitResolve(1e2));
  }

  try {
    for (const [key, value] of Object.entries(tasks)) {
      console.log(`Starting ${key}`);

      try {
        // Here the tasks of this group are executed, giving promises
        await Promise.all(value.map(task => task()));
      } catch (err) {
        console.log(`Caught error in ${key}!`, err);
      }

      console.log(`Finished ${key}`);
    }
  } catch (err) {
    console.log('Caught error in run!', err);
  }
};

run();