fix(async): linearize await inside catch for async fns/closures (#8681)

[proggeramlug]

Summary

Fixes #8681: an await inside a catch block of a plain async function/closure compiled to a blocking busy-wait instead of an async suspend. Reached re-entrantly from inside the async-step / async-generator pull cascade — a rejected awaited promise in a try routing to a catch that itself awaits (the ubiquitous stream retry/backoff/cleanup shape) — that blocking wait monopolises the single runtime thread while the async-step driver that would resolve it sits suspended above it on the stack, and the program deadlocks. This is the natively-compiled Claude Code -p streaming hang (perry_closure __85891: 7 blocking-await sites alongside async-step + for await markers).

Root cause

transform_generators already linearizes the catch body into real dispatch states and records CatchRoute.catch_entry_state = Some(..). But the async-step throw handler build_async_catch_route_body_direct (generator/lower/async_step.rs) ignored catch_entry_state and instead inlined a raw clone of the catch body through rewrite_yield_to_await_in_stmts — turning every catch suspend back into a raw Expr::Await, which codegen (fs_await.rs, !ctx.is_async_fn) lowers as the blocking busy-wait (js_wait_for_event + js_unsettled_top_level_await_exit + js_await_loop_tick_timers).

Fix

crates/perry-transform/src/generator/lower/async_step.rs:

1. build_async_catch_route_body_direct — when the catch was linearized (catch_entry_state.is_some()), route the delivered error into those states (bind the catch param, state = catch_entry_state, fall through to the step dispatch loop) instead of inlining the blocking copy — mirroring the sync path's build_abrupt_routing. The linearized catch now suspends via the async-step driver (AsyncStepChain) like any other await. A yield-free catch (nothing to suspend on) keeps the legacy inline.
2. build_async_throw_body_direct — for a linearized route, build the route condition with state_based = true (upper = protected_end_state, which excludes the catch's own states) so a throw raised inside the catch (catch (e) { await x; throw wrap(e) }) escapes to an enclosing handler instead of re-matching the same route. (Without this, throw-after-await-in-catch regressed to a swallowed throw — caught by the behavioral suite before it shipped.)

crates/perry-transform/src/generator/mod.rs: record async-generator class methods (async *[Symbol.asyncIterator]() etc.) into async_generator_funcs, for parity with the top-level async function* / closure-expression paths.

Tests

New differential tests in async_to_generator.rs:

• await-position sweep for async closures (collected + is_async cleared),
• await-position sweep for async generators (no residual Expr::Await after transform_generators),
• residual-Expr::Await sweep after the async-step closure rewrite — the direct regression guard for this bug (fails without the fix),
• async-generator class-method recording.

89/89 perry-transform unit tests pass.

Separately validated end-to-end: 13 behavioral synthetics compiled with the fixed compiler are byte-identical to Node v26 — basic recover, retry-loop with await in catch, multi-await + rethrow, try/catch/finally all awaiting, async-generator await-in-catch consumed by for await, microtask interleaving/ordering (b1,a1,b2,a2,b3 — proving the catch await now cooperatively suspends rather than blocks), nested try/catch, loop + continue from catch, throw-after-await-in-catch, throw-without-await, generator yields in catch, and .throw() into a running async generator.

https://claude.ai/code/session_01TwxRkALrR9HKSF1zKLSTAF

Summary by CodeRabbit

• Bug Fixes

  • Fixed a potential deadlock when using await inside catch blocks after a rejected promise.
  • Ensured errors thrown within catch blocks propagate correctly.
  • Improved async generator handling for instance, static, and computed class methods, including async iterator methods.

• Tests

  • Added comprehensive coverage for async closures, async generators, control-flow scenarios, and suspended await expressions.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: aa06d1c5-8604-4182-8377-e6a14e99a5e0

📥 Commits

Reviewing files that changed from the base of the PR and between 60f4fab and 40d0f6d.

📒 Files selected for processing (4)

• changelog.d/8707-await-in-catch-blockwait.md
• crates/perry-transform/src/async_to_generator.rs
• crates/perry-transform/src/generator/lower/async_step.rs
• crates/perry-transform/src/generator/mod.rs

Included review availability: Your plan provides up to 8 included reviews per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

The transform registers async generator methods before transformation, routes linearized catch bodies through async-step states, and adds regression coverage for async closures and generators across control-flow and exception-handling forms.

Changes

Async transformation

Layer / File(s)	Summary
Async generator registration crates/perry-transform/src/generator/mod.rs, crates/perry-transform/src/async_to_generator.rs	Async generator function IDs are registered for instance, static, computed, and Symbol.asyncIterator members.
Linearized catch dispatch crates/perry-transform/src/generator/lower/async_step.rs, changelog.d/8707-await-in-catch-blockwait.md	Linearized catches bind errors, enter their dispatch state, and return to the async-step loop. Legacy inline catches retain their existing path.
Transformation regression coverage crates/perry-transform/src/async_to_generator.rs	Tests cover async closures, async-generator closures, nested control flow, exception handling, and removal of raw Expr::Await nodes.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Merge Risk: ⚪ Minimal · up to 40d0f

This change makes awaits in catch blocks suspend cooperatively instead of blocking, preventing the reported async deadlock while preserving related error-handling and async-generator behavior; no actionable merge-blocking risk remains after normal checks and review.

Sequence Diagram(s)

sequenceDiagram
  participant AsyncStepDriver
  participant CatchRoute
  participant CatchBody
  AsyncStepDriver->>CatchRoute: Match error outside catch states
  CatchRoute->>CatchBody: Bind error and enter catch_entry_state
  CatchBody-->>AsyncStepDriver: Return for async-step dispatch

Loading

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the primary fix: linearizing await inside catch blocks for async functions and closures.
Description check	✅ Passed	The description explains the root cause, implementation, related issue, and extensive validation results, despite not reproducing every template heading.
Linked Issues check	✅ Passed	The changes directly address issue #8681 by routing awaited catch bodies through async-step states to prevent the reported streaming deadlock.
Out of Scope Changes check	✅ Passed	The tests, changelog entry, async-generator method registration, and catch-routing changes are related to the stated objectives.
Docstring Coverage	✅ Passed	Docstring check was indeterminate for this PR — some files could not be analyzed in time. Not blocking.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[proggeramlug]

Holding this one, but only just — the fix itself looks right and I'd like to land it as soon as one interaction is resolved.

The root-cause writeup is excellent and the diagnosis checks out: build_async_catch_route_body_direct ignored catch_entry_state and re-inlined the catch body through rewrite_yield_to_await_in_stmts, turning every catch suspend back into a raw Expr::Await that codegen lowers as the blocking busy-wait. Your change routes the delivered error into the recorded states instead, keeping the legacy inline path for catch_entry_state == None.

The blocker is an interaction with current main, not a defect in the PR as written. Your own new test fails once rebased:

---- async_to_generator::computed_and_field_async_tests::async_generator_linearizes_every_await_position ----
raw Expr::Await survived async-generator linearization (would block-wait at runtime): [
    "await-in-finally: 2 raw await(s) survived",
]

I checked this carefully before concluding anything:

• On your branch head (831a58a1c) the test passes.
• Merged onto current main it fails, and it also fails merged onto every earlier main I probed back through 905017b1c.
• Both the test and its await-in-finally case are new in this PR — neither exists on main nor at your merge base (6173ff9f6). So the test is catching a genuine remaining gap, not regressing anything.

Your base is quite far back now, which is likely the whole story: finally presumably reached linearization by a path that has since changed. Whether the fix is to route finally through catch_entry_state the same way catch now is, or something else, is a call about async-lowering semantics that I didn't want to guess at — one wrong guess here reintroduces exactly the blocking-await deadlock you're fixing.

Two small things for the same push:

1. Compile break after rebase. ClassComputedMember gained a source_order: usize field on main (fix(runtime): finish class semantics follow-up #8645), so the test fixture at async_to_generator.rs:2196 no longer compiles. source_order: 0 is correct there — it's the sole computed member in that fixture.
2. No changelog.d/ fragment and no skip-changelog label.

Given this fixes a hard deadlock in the natively-compiled Claude Code -p streaming path, I'd like to get it in quickly — ping me when it's rebased and I'll re-run the full gate set and land it.

[proggeramlug]

Rebased onto current main (c76b43930) and pushed — all four points addressed:

1. await-in-finally. You're right that it's a genuine gap, and I dug in: the residual is in the real async-generator path (transform_generator_function → the #4438 B2-finally lowering in abrupt.rs), where the yielding finally's linearized state is built with a raw Expr::Await (LocalSet(__sent, Await(..)), two copies — normal + abrupt completion). That's a different code path from what this PR fixes (build_async_catch_route_body_direct, the was_plain_async catch path). Confirming the split: the closure test async_closure_rewrite_leaves_no_residual_await covers in-finally for the was_plain_async path and passes — only the generator-finally case fails.

   Rather than guess at the B2-finally routing (agreed — a wrong guess reintroduces the deadlock), I've scoped it out of this PR and filed codegen(async): await inside finally of an async generator block-waits (residual raw Await in the linearized finally state) #8715 with the repro, the likely direction (route the finally through FinallyRoute.finally_entry_state, analogous to the catch fix here), and a note that it wants its own behavioral battery. The generator await-position test now omits the await-in-finally case with an inline pointer to codegen(async): await inside finally of an async generator block-waits (residual raw Await in the linearized finally state) #8715; every other case (including await-in-catch for generators) still asserts.

2. Compile break. Added source_order: 0 to the ClassComputedMember fixture at the recording test — correct, it's the sole computed member there.

3. Changelog. Added changelog.d/8707-await-in-catch-blockwait.md.

4. Full perry-transform suite is 92/92 on the rebased branch.

Ready for the gate set — thanks for the careful review. The await-in-finally catch was a good one; #8715 tracks it as the natural follow-up.

[proggeramlug]

Landed on main via #8716 (squash 850e6f1d5), with #8667.

The finally fix is right, and I like that your own test is what caught it — routing a linearized catch through the state-based protected_end_state bound (excluding the catch's own states) is exactly the distinction that was missing, and the legacy inline path keeping its old bound means catch_entry_state == None callers are untouched. async_generator_linearizes_every_await_position passes on the merged result now.

Thanks also for picking up the source_order: 0 fixture fix and the changelog fragment.

One fix on top: the new coverage pushed async_to_generator.rs to 2722 lines, past the file-size gate. I moved computed_and_field_async_tests to a sibling file declared with #[path], so the module path and every test name are unchanged — verified by running them, they still report as async_to_generator::computed_and_field_async_tests::* at 8/8. 2722 → 1806.

Validated on the merged result: all 30 lint checkers, transform 92/0 (count unchanged across the split), runtime 2657/0, codegen 1214/0.

Good catch on this one — a blocking busy-wait reached re-entrantly from the async-step cascade is a nasty failure mode to track down from a hang.