[littledivy]

Embedders chaining on a promise internally (module loaders, host APIs that observe a promise's settlement) currently have to call the then property, which user code can override, or hand-roll reactions with JS_NewPromiseCapability plus JS glue. This adds JS_PromiseThen, which performs PerformPromiseThen directly: the result promise is created with the intrinsic constructor, so an overridden then() or Symbol.species is never consulted and cannot interfere.

Handlers may be undefined (identity/thrower per spec). A non-promise argument throws a TypeError. V8 exposes the same operation as v8::Promise::Then.

Covered in api-test.c, including a subclass with poisoned then/Symbol.species that JS_PromiseThen must not invoke.

Disclaimer: This is an AI-assisted patch from the v8x project.

[saghul]

Not sure I fully follow here. If the promise is passed along from user code to C, we should call the then / Symbol.species shouldn't we?

[littledivy]

This exposes PerformPromiseThen - it's what await and the ES module machinery use for ContinueDynamicImport and ExecuteAsyncModule or when the embedder wants to know when the promise settles even if user code patched then:

Promise.prototype.then = null; // host must still observe settlement