"React to a promise" is not equivalent to Promise.prototype.then with missing handlers

[andreubotella]

The "react to a promise" algorithm seems to be a spec-level version of Promise.prototype.then, except that when it's called with a missing handler, a default handler is substituted which simply resolves the promise with undefined.

In other words, you would expect "react to a promise" to be equivalent to:

// promise: Promise<T>
// onFulfillment?: (T) => U
// onRejection?: (any) => U
promise.then(onFulfillment, onRejection) // Promise<U>

and it's instead:

promise.then(onFulfillment ?? () => undefined, onRejection ?? () => undefined) // Promise<U | undefined>

I understand that, even when there's no fulfillment handler given, the conversion to IDL of the resolved value must happen, so the promise can reject if the conversion throws (see also #782). But even in that case, the return value shouldn't be undefined. And for the rejection handler even that is unnecessary, since converting an ECMAScript value to any cannot fail.

The fact that this is the intended behavior is borne out by the definitions of "upon fulfillment" and "upon rejection", as well as by the usage of these operations in the Fetch, Streams, Background Fetch and Service Worker specs.

[domenic]

Yeah, this seems pretty bad. Are you interested in working on a PR to fix this?

[andreubotella]

Yeah, this seems pretty bad. Are you interested in working on a PR to fix this?

Sure!