PR #91704: fix(swc): replace async generator in subscribe() with manual iterator to prevent pendingOperations Map overflow

• Repository: vercel/next.js
• Author: z4nr34l
• State: open | merged: False
• Link: https://github.com/vercel/next.js/pull/91704

Description (problem / solution / changelog)

What

Replaces the async function* createIterator() generator inside subscribe() in packages/next/src/build/swc/index.ts with a manually-implemented AsyncIterableIterator that returns Promise<IteratorResult<T>> directly from next().

Closes / related: #85666

Why

The crash

In dev mode (Turbopack), subscribe() is used to create one HMR subscription per compiled server chunk (via project.hmrEvents()). For a large application with many routes, dozens or hundreds of these subscriptions run simultaneously as infinite for await…of loops:

hot-reloader-turbopack.js
  └─ for await (const result of subscription) { … }
       └─ subscription = project.hmrEvents(chunkPath, HmrTarget.Server)
            └─ subscribe(true, …)  ← async generator lives here

React 19's dev-mode async profiler registers a Node.js AsyncHook (inside the compiled app-page-turbo.runtime.dev.js) that tracks every async resource in a pendingOperations Map, capturing a full stack trace per entry. The destroy hook is supposed to remove entries once async resources are garbage-collected, but under heavy HMR activity GC cannot keep up with creation.

This pendingOperations Map was independently identified as the leak source in #85666 (see this comment).

Why async generators make it worse

An async function* generator produces multiple async hook IDs per event:

That is 3–4 async IDs per event, each stored in pendingOperations with a captured stack trace (≈1–5 KB per entry). With many active subscriptions producing frequent events the Map grows faster than V8's GC can drain it until V8 can no longer allocate memory for the Map's internal hash table:

RangeError: Map maximum size exceeded
    at Map.set (<anonymous>)
    at AsyncHook.init (…/app-page-turbo.runtime.dev.js:53:268561)
    at emitInitNative (node:internal/async_hooks:206:43)
    at promiseInitHookWithDestroyTracking (node:internal/async_hooks:336:3)
    at createIterator (…/next/dist/build/swc/index.js:512:31)
    at …/next/dist/server/dev/hot-reloader-turbopack.js:127:30

The server process exits after a few minutes of active development.

The fix

A manual async iterator returns exactly one Promise<IteratorResult<T>> from next() — no generator object, no step-Promise wrapping, no extra Promise.resolve() from for await…of. This reduces async-resource creation from O(events × 3–4) to O(events × 1), keeping pendingOperations bounded rather than growing without limit.

Semantics are identical: buffered events drain instantly via Promise.resolve(), and the "waiting" path resolves or rejects the returned Promise when emitResult fires. Task cleanup is moved into return() (previously it lived in the generator's finally block, which was only reachable after the generator resumed — a path that the overridden iterator.return bypassed anyway).

Testing

Start the dev server for a large Next.js / Turbopack app (many routes, active file editing) on Node.js v22+. Before this fix the server crashes with RangeError: Map maximum size exceeded after a few minutes. After this fix the server remains stable indefinitely under the same workload.

Verified on Node.js v24.11.1 + Next.js 16.2.0.

Changed files

• packages/next/src/build/swc/index.ts (modified, +72/-27)