[Turbopack] Infinite Suspense remount cycle with React.lazy() + 15+ useSyncExternalStore selectors

[mmmprod]

Link to the code that reproduces this issue

https://github.com/mmmprod/turbopack-suspense-remount-repro

To Reproduce

1. Clone the repo: git clone https://github.com/mmmprod/turbopack-suspense-remount-repro
2. npm install
3. npm run dev (Turbopack, default in Next.js 16)
4. Open http://localhost:3000 in browser
5. Open browser console (F12)
6. Observe [HeavyComponent] render mount=XXXX logs — each pair has a different mount ID, meaning the component is unmounted and remounted infinitely

Current vs. Expected Behavior

Current: The lazy-loaded component enters an infinite unmount/remount cycle. Each mount gets a new React instance (different useRef value). The page never becomes interactive.

Expected: The component should mount once (+ StrictMode double), render, and stay mounted.

Only affects Turbopack dev mode

Mode	Result
next dev (Turbopack)	Infinite remount loop
next dev --webpack	Works perfectly
next build && next start	Works perfectly

Environment

• Next.js: 16.2.2
• React: 19.2.4
• Node.js: 20.20.0
• OS: Linux (WSL2)

Component characteristics

The reproduction component has 15+ Zustand useSyncExternalStore selectors across 3 stores, useContext consumer, 4 useMemo, 3 useCallback, 2 useEffect. Loaded via React.lazy() inside Suspense.

Simpler components with 2-3 selectors do NOT reproduce.

Workaround

Eager-import the component in dev, lazy in prod:

import { HeavyComponent as Eager } from "./HeavyComponent";
const HeavyComponent = process.env.NODE_ENV === "production"
  ? lazy(() => import("./HeavyComponent").then(m => ({ default: m.HeavyComponent })))
  : Eager;

Which area(s) are affected?

Turbopack

Which stage(s) are affected?

next dev (Development)

[sleitor]

Investigation Report

I spent several hours trying to reproduce the infinite remount cycle on a native Linux machine (Oracle Cloud ARM64, Node 22, Next.js 16.2.2, React 19.2.4) using the exact reproduction repo.

What I observed

Single remount on every page load — both Turbopack and Webpack:

# Turbopack (next dev)
mount=d8k9 #1, #2   → mount=kdj4 #1, #2, #3, #4

# Webpack (next dev --webpack)  
mount=7d60 #1, #2   → mount=06c3 #1, #2, #3, #4

Both bundlers produce the identical pattern: one remount (2 mount IDs), then stable. This appears to be normal React behavior — hydration of React.lazy() inside Suspense causes a client-side re-render when the lazy promise resolves asynchronously.

What I could NOT reproduce

The infinite remount loop described in the issue. Even with:

• Artificial 2-3 second delays on HMR WebSocket messages (simulating slow I/O)
• Both reactStrictMode: true and false
• Light component (2 selectors) vs heavy component (15+ selectors) — both remount identically

Instrumented runtime findings

I patched the Turbopack dev runtime with tracing in key HMR functions (applyEcmascriptMergedUpdate, handleApply, disposeModule, registerExportsAndSetupBoundaryForReactRefresh). Results:

1. Zero HMR callbacks fire during the remount — no applyEcmascriptMergedUpdate, no handleApply, no module disposal
2. The [Fast Refresh] rebuilding log that appears after mount is a false alarm — it comes from Turbopack's BUILDING/BUILT events (which fire for any compilation, including no-ops), not from actual module updates
3. The remount happens before any HMR activity

WSL2 hypothesis

The issue reports Linux (WSL2) as the environment. WSL2 has known issues with cross-filesystem I/O and inotify file watching. My hypothesis is that on WSL2, turbo-tasks may recompute module hashes during initial load due to filesystem timestamp instability, generating real HMR partial updates that re-evaluate page.tsx → create new React.lazy() reference → remount → trigger another recomputation → infinite loop.

This would explain:

• Why it only affects Turbopack (turbo-tasks file watching) and not Webpack
• Why heavier components are more affected (longer render time = bigger window for the race condition)
• Why it cannot be reproduced on native Linux with stable filesystem

Could the reporter confirm?

1. Is the project directory on the Windows filesystem (/mnt/c/...) or the Linux filesystem (~/...)? WSL2 performance is dramatically worse on /mnt/c/.
2. Does the issue reproduce with the project on the Linux filesystem?
3. Can you share a screenshot of the console showing the infinite loop pattern?

This would help narrow down whether this is a WSL2-specific file watching issue or something else entirely.

[mmmprod]

Hey @sleitor, thanks for digging into this, the runtime instrumentation was solid work and it actually helped us find the real issue.

To your questions:

1. Linux filesystem, not /mnt/c/. It's ext4 on a virtual disk (/dev/sdd), so 9p isn't in the picture.

2. Yeah, same result on the Linux fs.

3. So we actually found the root cause and it's embarrassing, it was our code, not Turbopack.

Our LocaleProvider was creating new function refs on every render. Classic anti-pattern: const t = (key) => { ... } inline instead of useCallback. Every component using useTranslations() got a new t ref each render, which cascaded through the entire tree (most of our components use translations).

The fix was textbook React:

// Before: new ref every render → cascade
const t = (key: string) => { /* lookup */ };

// After: stable ref
const t = useCallback((key: string) => { /* lookup */ }, [messages, locale]);
const value = useMemo(() => ({ t, locale, ... }), [t, locale, ...]);

But here's the thing that's still interesting for the Next.js team:

The exact same buggy code behaves very differently between bundlers:

• next dev --webpack: re-render cascade, page sluggish but functional
• next dev (Turbopack) + React.lazy(): cascade escalates into full Suspense unmount/remount cycles, 300+ mounts/sec, page completely frozen
• next build && next start: no issue at all

So the user code bug is ours, but Turbopack's HMR turns a perf issue into a hard crash when combined with React.lazy(). Webpack handles the same cascade gracefully.

Your finding that zero HMR callbacks fire during the remount is key, the cascade is purely in the React render layer, not in module invalidation. But something about Turbopack's dev runtime makes Suspense boundaries more aggressive about tearing down lazy components during render storms.

Re: the reproduction repo I couldn't get it to loop in a minimal setup. The cascade needs enough module graph activity (~700 modules in our app) for the HMR feedback to kick in. With 5 files it settles immediately. I'll update the repo README to explain this, sorry about the incomplete repro.

If you want I can keep this issue open as a behavioral difference report (Turbopack vs Webpack Suspense resilience), or close it since the root cause was user code. Your call.

[victorlangston123-droid]

Thank you for the update and for identifying the root cause within the LocaleProvider. It’s a great catch, and it's helpful to know that the stable reference fixed the primary issue.

…

On Sun, Apr 5, 2026, 4:40 PM MMMProd ***@***.***> wrote: *mmmprod* left a comment (vercel/next.js#92372) <#92372 (comment)> Hey @sleitor <https://github.com/sleitor>, thanks for digging into this — the runtime instrumentation was solid work and it actually helped us find the real issue. To your questions: *1.* Linux filesystem, not /mnt/c/. It's ext4 on a virtual disk (/dev/sdd), so 9p isn't in the picture. *2.* Yeah, same result on the Linux fs. *3.* So we actually found the root cause and it's embarrassing — it was our code, not Turbopack. Our LocaleProvider was creating new function refs on every render. Classic anti-pattern: const t = (key) => { ... } inline instead of useCallback. Every component using useTranslations() got a new t ref each render, which cascaded through the entire tree (most of our components use translations). The fix was textbook React: // Before: new ref every render → cascadeconst t = (key: string) => { /* lookup */ }; // After: stable refconst t = useCallback((key: string) => { /* lookup */ }, [messages, locale]);const value = useMemo(() => ({ t, locale, ... }), [t, locale, ...]); *But here's the thing that's still interesting for the Next.js team:* The exact same buggy code behaves very differently between bundlers: - next dev --webpack: re-render cascade, page sluggish but functional - next dev (Turbopack) + React.lazy(): cascade escalates into full Suspense unmount/remount cycles, 300+ mounts/sec, page completely frozen - next build && next start: no issue at all So the user code bug is ours, but *Turbopack's HMR turns a perf issue into a hard crash* when combined with React.lazy(). Webpack handles the same cascade gracefully. Your finding that zero HMR callbacks fire during the remount is key — the cascade is purely in the React render layer, not in module invalidation. But something about Turbopack's dev runtime makes Suspense boundaries more aggressive about tearing down lazy components during render storms. *Re: the reproduction repo* — I couldn't get it to loop in a minimal setup. The cascade needs enough module graph activity (~700 modules in our app) for the HMR feedback to kick in. With 5 files it settles immediately. I'll update the repo README to explain this, sorry about the incomplete repro. If you want I can keep this issue open as a behavioral difference report (Turbopack vs Webpack Suspense resilience), or close it since the root cause was user code. Your call. — Reply to this email directly, view it on GitHub <#92372 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CAXXQK2GBOYZ4SLORHLFLIL4ULHEBAVCNFSM6AAAAACXNBJGNGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCOBZGU3TEMJYGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>