Nested async-await hangs: `await asyncFn()` where asyncFn itself awaits never resolves

[proggeramlug]

Summary

A two-level deep await chain — i.e. an async function whose body contains an await, called via await/.then/bare from another async context — hangs forever and produces zero output. This is a pre-existing bug (reproduces on v0.5.498 too, not v0.5.503-specific) but is currently masked from the parity sweep because test_async.ts is in run_parity_tests.sh::SKIP_TESTS. The same shape causes test-files/test_gap_async_advanced.ts to hang silently.

Minimal repro

async function getValue(): Promise<number> {
  return 42;
}

async function run(): Promise<void> {
  const x = await getValue();   // <- await inside the body
  console.log(x);
}

await run();
console.log(100);

Expected (matches node --experimental-strip-types): prints 42 then 100.
Observed: zero output, infinite spin (still alive after 60+ seconds at 100% CPU on kill -9 only).

Pinning

Variant	Result
Top-level await Promise.resolve(42)	works
await getValue() at top-level (one-level)	works
await new Promise(r => r(42)) inside async main()	works
await Promise.resolve(42) inside async main(), main() called bare	hangs
main().then(() => …) instead of bare call	hangs
await run() where run itself awaits another async fn	hangs

The trigger is an async function whose body contains an await, invoked from a top-level execution path that schedules the resulting promise. One-deep await works; the second await never resumes the outer.

Repro file

test-files/test_async.ts (already in the repo, currently skip-listed in run_parity_tests.sh):

async function getValue(): Promise<number> { return 42; }
async function run(): Promise<void> { let x = await getValue(); console.log(x); }
await run();
console.log(100);

Why this matters

• Almost all real-world TypeScript code follows the async function main() { … } main().catch(…) pattern.
• Today the hang is masked because:
  • test_async.ts is in the parity SKIP_TESTS array (commented "Async tests need event loop"), so the 167/167 sweep doesn't catch it.
  • test_gap_async_advanced.ts is in the gap suite but produces zero output before the runner times out, getting recorded as a generic FAIL without surfacing the hang nature.
• Anything more ambitious than a single top-level await will silently brick.

Suggested fixes

1. Investigate why a nested await doesn't drive its outer promise to completion — likely the microtask queue isn't being pumped after the inner promise settles, or the outer continuation isn't being enqueued correctly.
2. Once fixed, un-skip test_async/test_async2…5/test_async_chain in run_parity_tests.sh::SKIP_TESTS so the parity sweep covers this surface.

Verified pre-existing

git checkout HEAD~5 -- crates/ && cargo build --release (v0.5.498) — repro hangs identically. So this is not a v0.5.503 / v0.5.502 / v0.5.501 / v0.5.500 / v0.5.499 / v0.5.498 regression; it predates that window.

[proggeramlug]

Investigation summary from worktree-agent (full transcript not posted — too long). Agent did not commit a fix — root cause analysis follows.

Where the bug lives

The trigger is the async-to-generator state-machine driver (crates/perry-transform/src/async_to_generator.rs + generator.rs::build_async_step_driver, lines 1081–1342). When a plain async function contains an await, that pass rewrites it into a generator wrapped in a recursive __step(value, isError) closure that loops via Promise.resolve(r.value).then(__step_v, __step_e). run() in the repro takes this path; getValue() (no inner await) does NOT — it stays as a plain async returning js_promise_resolved(42).

What goes wrong

The microtask runner enters an infinite loop. Each cycle: pops the outer promise, calls __step with undefined/false, __step re-enters the iterator with iter.next(undefined) via js_native_call_method, then chains Promise.resolve(r.value).then(__step_v, __step_e). r.value is repeatedly TAG_UNDEFINED so the chain enqueues another Promise.resolve(undefined) step, indefinitely.

Smoking gun

getValue() is never called — the trace shows no js_promise_resolved(42) allocation. State-0 of the iterator (the only path that calls getValue) doesn't fire. The only way to observe r.value=undefined, r.done=false is if r is NULL_OBJECT_BYTES returned by js_native_call_method when the method isn't found. Most plausible root cause: the iter handle captured at index 0 of the __step closure points to garbage — likely because run() is annotated alwaysinline (crates/perry-codegen/src/codegen.rs:2140 — if f.body.len() <= 8 && !f.is_async && !f.is_generator { f.alwaysinline = true; }; the rewritten run() has is_async=false, is_generator=false, was_plain_async=true, so the gate fires) and after inlining into main(), the shadow slot for iter doesn't survive the inline.

Proposed fixes (in order of preference)

Option A (smallest): add && !f.was_plain_async to the alwaysinline gate at codegen.rs:2140. One line, fully revertible. If GC-root-after-inlining is the cause, this fixes it.

Option B: ensure iter stays rooted across the step-closure lifetime — either via explicit GC-traced capture-list in js_closure_set_capture_f64 or by auditing shadow-stack push/pop count after run() is inlined.

Option C (larger refactor): replace the recursive Promise.resolve(...).then(__step, __step) chain with a flatter loop in build_async_step_driver that doesn't need GC roots to live across each tick.

Files involved

• crates/perry-transform/src/generator.rs:1057,1063,1111-1342 — async-step driver construction
• crates/perry-codegen/src/codegen.rs:2140 — alwaysinline gate
• crates/perry-runtime/src/object.rs:3704 — js_native_call_method (unknown-method fallback returns NULL_OBJECT_BYTES at 4395)
• crates/perry-runtime/src/promise.rs:128,257,490,619 — promise resolve/then/run_microtasks/resolved
• crates/perry-codegen/src/expr.rs:7860 — Expr::Await busy-wait

Risk

Six skip-listed tests in run_parity_tests.sh::SKIP_TESTS (test_async, _async2...5, _async_chain) share this code path. Wider blast radius covers async fetch (#84), Promise chaining (#236, #256, #269), async-step driver (#212), microtask FIFO ordering. The async-to-generator pre-pass has 7 prior bisection-comments — fragile area.

I'll attempt Option A as a follow-up commit.

[proggeramlug]

Partial fix landed: v0.5.506 (commit 5254828). Option A applied: !f.was_plain_async added to the alwaysinline gate at codegen.rs:2140.

What's fixed: the infinite-microtask hang is gone. The repro now exits cleanly instead of spinning forever at 100% CPU.

What's still broken: the rewritten function's body still doesn't execute. The repro's console.log(x) inside run() doesn't fire, and [PERRY WARN] js_box_get: invalid box pointer 0x0 prints — suggesting a deeper GC-root or closure-capture bug in the async-to-generator pre-pass that's independent of the inlining problem. Issue stays open for follow-up.

The 6 skip-listed test_async* tests in run_parity_tests.sh::SKIP_TESTS remain skip-listed since they still don't pass; un-skipping should wait for the deeper fix.

Workspace tests 646/646 pass with the change; simple async (single-level) still works.

[proggeramlug]

Fully fixed in v0.5.509 (commit 58cbb2a — verification + un-skip; the actual fix shipped in v0.5.508 commit beb60ac).

The deeper "body doesn't execute" bug noted in the v0.5.506 partial-fix comment turned out to be the same root cause as #448 + #451: the ABI mismatch on js_object_set_field (declared DOUBLE, runtime takes u64 — closure pointers landed in xmm0/d0 instead of rdx/x2). The async-to-generator pre-pass synthesizes a { next, return, throw } iter object whose closure fields hit the same shape-cache fast path; once those closures stored as 0, iter.next() dispatched against undefined and the body never ran.

Verified post-v0.5.508:

• v0.5.506's partial-fix repro now prints 42 / 100 matching node (was: 100 only with js_box_get null warning).
• test_gap_async_advanced.ts prints all 28 lines including "ALL ASYNC ADVANCED TESTS PASSED" (was: hung indefinitely with zero output).
• test_async / _async2 / _async3 / _async4 / _async5 / _async_chain un-skipped from run_parity_tests.sh::SKIP_TESTS — all 6 match node modulo node-v25 warning chatter that normalize_output strips.

Three issues (#447 + #448 + #451) collapsed into one root cause + one functional fix (3 lines in 2 files).