Fix reporting handled promises as unhandled in tracker

[saghul]

Enqueue a job which will perform the check after all reactions. Also drop the case in which the tracker gets called with true, the handler now only gets called when the promise rejection is unhandled.

Fixes: #39

[saghul]

@bnoordhuis LMK what you think about this change. I can drop the 2nd commit and leave it more backwards compatible.

[bnoordhuis]

Without is_handled, you can't implement async_hooks, so either it needs to be restored or there should be a promise hook for rejected promises.

[saghul]

Got it, I'll rework it.

[nabetti1720]

Without is_handled, you can't implement async_hooks, so either it needs to be restored or there should be a promise hook for rejected promises.

It would be great if the new Promise Hook API could also pick up rejections. :)
It is a bit complicated that the methods for detecting asynchronous events are divided into the PromiseHook API, Promise Rejection Tracker, and FinalizationRegistry, so I think it would be a good idea to integrate the Promise Rejection Tracker into the PromiseHook API. However, I don't know the history of the Promise Rejection Tracker, so if you can't integrate it, that's fine.

[saghul]

I suppose I could add a new hook JS_PROMISE_HOOK_REJECT and then an extra API JS_PromiseIsHandled and we could drop this altogether.

Thoughts @bnoordhuis ?

[bnoordhuis]

Without is_handled, you can't implement async_hooks, so either it needs to be restored or there should be a promise hook for rejected promises.

[saghul]

@bnoordhuis Updated, PTAL!

[ChALkeR]

@saghul Still reproducible on this:

const asyncFunction = async () => {
  throw new Error('this function rejects')
}

async function run() {
  const error = await Promise.resolve().then(function () {
    var resultPromise = asyncFunction();
    return Promise.resolve().then(function () {
      return resultPromise;
    }).then(function () {
      return null;
    }).catch(function (e) {
      return e;
    });
  });
  console.log('Got this error:', error)
}

run().then(() => console.log('done'))

Code mostly extracted from http://npmjs.com/package/assert assert.rejects() (which also crashes on QuickJS)

[saghul]

Dammit, I'll take another look! Thanks for the test case!

[ChALkeR]

Simplified test case:

const error = await Promise.resolve().then(() => Promise.reject('reject')).catch(e => e)
console.log('Got this error:', error)

[saghul]

@ChALkeR My attempt at covering that: #1049

[andycall]

I don't believe this patch is correct—it introduces behavior that's inconsistent with Web browser implementations.

Take the following code example in a web browser. Only 'rejected' is printed to the console:

window.addEventListener('unhandledrejection', event => {
  console.log('unhandledrejection fired: ' + event.reason);
});

window.addEventListener('rejectionhandled', event => {
  console.log('rejectionhandled fired: ' + event.reason);
});

function generateRejectedPromise(isEventuallyHandled) {
  // Create a promise which immediately rejects with a given reason.
  var rejectedPromise = Promise.reject('Error at ' + new Date().toLocaleTimeString());
  rejectedPromise.catch(() => {
    console.log('rejected');
  });
}

generateRejectedPromise(true);

This demonstrates that the caller (the Window object) tracks unhandled promise rejections. The initial rejection is considered unhandled and would trigger the unhandledrejection event. Later, when .catch() is added, the promise becomes handled.

For users who register a callback with JS_SetHostPromiseRejectionTracker, they should simply record the reported promise pointer in a map, and remove it once the promise is handled by user code.

Reference:
https://github.com/openwebf/webf/blob/main/bridge/core/executing_context.cc#L630

However, the current patch sets is_handled to true for both the unhandled and handled states, making it impossible to accurately detect whether a promise was truly handled or not. This undermines the ability to track unhandled rejections as the spec and browser behavior intend.

[andycall]

I don't believe the Promise feature in Bellard's 2021-03-27 version had any issues.

The problems stemmed from a misunderstanding of how Promise rejections were handled and reported. I've used this implementation in WebF for over four years, powering frameworks like React, Vue, and Jasmine, as well as open-source tools such as Ant Design—from its initial open-source phase to its application in enterprise crypto projects.

Rolling back to Bellard’s original implementation and referring to the WebF usage should resolve the issues.

[saghul]

I don't believe this patch is correct—it introduces behavior that's inconsistent with Web browser implementations.

I don't think the intention was that from the start though. Rather, how to terminate the process in unhandled rejection cases which server runtimes implement.

This demonstrates that the caller (the Window object) tracks unhandled promise rejections. The initial rejection is considered unhandled and would trigger the unhandledrejection event. Later, when .catch() is added, the promise becomes handled.

How would a server runtime know when to terminate the process in case of an unhandled rejection then?

However, the current patch sets is_handled to true for both the unhandled and handled states, making it impossible to accurately detect whether a promise was truly handled or not. This undermines the ability to track unhandled rejections as the spec and browser behavior intend.

Note I made a follow-up PR handling more corner cases.

[andycall]

How would a server runtime know when to terminate the process in case of an unhandled rejection then?

I think the termination of the process should depend on the currently enqueued microtasks or any active event listeners. Regardless of whether the callback executes successfully or throws an exception, the process should not terminate immediately. If an exception is thrown, it should simply emit an event on globalThis.

[saghul]

Node, Deno and Bun disagree so there is ample precedent here.

[bnoordhuis]

If an exception is thrown, it should simply emit an event on globalThis.

It sounds like you're thinking of what Node.js does but that's in no way standard. There is no standard, it's up to the embedder - not the JS engine - to decide what's best.

[andycall]

Emm, if you wish to terminate the process when an unhandled async exception is thrown, it might be better to perform the check at the end of this enqueue job instead of immediately. This is because the user might catch and handle the error after the promise is created.

// Finish all the pending jobs
int finished = JS_ExecutePendingJob(script_state_.runtime(), &pctx);

while (finished != 0) {
  finished = JS_ExecutePendingJob(script_state_.runtime(), &pctx);
  if (finished == -1) {
    break;
  }
}

// Terminate the process if there are unhandled exceptions.
if (haveUnhandledExceptions) {
  exit(1);
}

[saghul]

Let me give that a try.

[saghul]

Fix: #1058