Top-level await incorrectly awaits promise continuation in REPL

[tniessen]

Version

18.5.0

Platform

Linux 5.13.0-Ubuntu x86_64 x86_64 x86_64 GNU/Linux

Subsystem

repl

What steps will reproduce the bug?

In REPL:

const foo = async () => 123;

foo();

await foo();

typeof (await Promise.resolve(foo))();

(await Promise.resolve(foo))();

How often does it reproduce? Is there a required condition?

Always.

What is the expected behavior?

> const foo = async () => 123;
undefined
> foo();
Promise {
  123,
  [Symbol(async_id_symbol)]: 33,
  [Symbol(trigger_async_id_symbol)]: 5
}
> await foo();
123
> typeof (await Promise.resolve(foo))();
'object'
> (await Promise.resolve(foo))();
Promise {
  123,
  [Symbol(async_id_symbol)]: 108,
  [Symbol(trigger_async_id_symbol)]: 5
}

Note that typeof prints 'object', which is correct and matches Promise { ... }.

What do you see instead?

> const foo = async () => 123;
undefined
> foo();
Promise {
  123,
  [Symbol(async_id_symbol)]: 33,
  [Symbol(trigger_async_id_symbol)]: 5
}
> await foo();
123
> typeof (await Promise.resolve(foo))();
'object'
> (await Promise.resolve(foo))();
123

Note that typeof prints 'object', which is correct, but the value of the expression is shown to be 123 in the REPL, which is a 'number'.

Additional information

Chrome and Edge seem to handle this as I'd expect. Firefox seems to handle this like Node.js (so I'm assuming it's a bug).

[aduh95]

@guybedford FYI

[guybedford]

@tniessen the repl top-level await doesn't use v8 directly and instead runs through an emulation layer. Short of someone to do the work to refactor that hack, this is a bug in the emulation layer originally implemented I believe by Gus.

The transform is here - https://github.com/nodejs/node/blob/main/lib/internal/repl/await.js, and the tests for the rewriting are here - https://github.com/nodejs/node/blob/main/test/parallel/test-repl-preprocess-top-level-await.js.

I would suggest adding the failing line to the transform tests to debug further what it is actually executing and why it is giving the wrong result. Working out the failing test would be a good start.

[tniessen]

Thank you for the info @guybedford!

I might be missing something but the transform seems to always wrap the code in an async function:

node/lib/internal/repl/await.js

Lines 155 to 156 in 90bc773

	const wrapPrefix = '(async () => { ';
	const wrapped = `${wrapPrefix}${src} })()`;

The REPL then seems to await the return value of that function:

node/lib/repl.js

Lines 571 to 575 in a055337

	if (self.useGlobal) {
	result = script.runInThisContext(scriptOptions);
	} else {
	result = script.runInContext(context, scriptOptions);
	}

node/lib/repl.js

Line 602 in a055337

let promise = result;

node/lib/repl.js

Lines 617 to 621 in a055337

	(async () => {
	try {
	const result = await promise;
	finishExecution(null, result);
	} catch (err) {

In this case, the value that the REPL should evaluate to is a Promise itself, and returning a Promise from the added async function causes the above snippet to incorrectly await the Promise.

I would suggest adding the failing line to the transform tests to debug further what it is actually executing and why it is giving the wrong result. Working out the failing test would be a good start.

I'm not sure what I'd expect the transform to produce. Maybe something like (async () => { return (await Promise.resolve(foo)); })().then((x) => x()) (which seems dangerously complicated).

[devsnek]

I think the solution is to rewrite all return v to return { value: v } and then get that value property on the outside.

[tniessen]

@devsnek That seems like an amazingly simple solution to me! See #43827.