next disregarding Suspense

[Robstei]

Link to the code that reproduces this issue

https://github.com/Robstei/next-suspense-needs-timeout

To Reproduce

1. Start the apllication
2. Clicking on Page1 provides immediate feedback. This is my expected and desired beheavour.
3. Page3 is the same as Page1 without this line

    await new Promise((r) => setTimeout(r, 10));

Page3 is slow and does not show the Suspense fallback

Current vs. Expected behavior

I would expect Page3 to behave like Page1.

1. Responde immediatly to navigation
2. Render Suspense fallback
3. render final page

Currently it does only work when i use

await new Promise((r) => setTimeout(r, 10));

as shown on Page3

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP Tue Nov 5 00:21:55 UTC 2024
  Available memory (MB): 7790
  Available CPU cores: 12
Binaries:
  Node: 22.11.0
  npm: 10.9.0
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 15.1.7 // Latest available version is detected (15.1.7).
  eslint-config-next: 15.1.7
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Not sure

Which stage(s) are affected? (Select all that apply)

next start (local)

Additional context

No response

[SharanKarchella]

I was able to get Page3 working correctly by making the following changes:

1️⃣ Forced the page to be dynamic by adding this at the top of Page3.tsx:
export const dynamic = "force-dynamic";

2️⃣ Added a small delay in the promise to ensure ArrayDisplay suspends properly:

const arrayPromise = new Promise<number[]>((resolve) => {
setTimeout(() => {
resolve(Array.from({ length: 100_000 }, (_, i) => i));
}, 10); // Ensures Suspense triggers
});

[Robstei]

Hi @SharanKarchella. I think export const dynamic = "force-dynamic"; is not needed.

You just recreated Page3 where I am using a Timeout already or am I wrong?

[SharanKarchella]

Originally, Page3 didn’t have setTimeout, which is why Suspense wasn’t working. Adding setTimeout(…, 10) makes sure the fallback appears before the final content loads. Yes you're right export const dynamic is not needed!

[samcx]

Page2 uses RSC and is somewhat slow but behaves like I would expect

To clarify, every page in App Router uses RSC.

The important thing is whether these pages will be prerendered at build time or not. Running the build confirms that every page will be prerendered, similar to when you have a fetch() → https://nextjs.org/docs/app/building-your-application/data-fetching/fetching#fetching-data-on-the-server-with-the-fetch-api.

If you are not using any Dynamic APIs anywhere else in this route, it will be prerendered during next build to a static page.

   ▲ Next.js 15.2.0-canary.71

   Creating an optimized production build ...
 ✓ Compiled successfully
 ✓ Linting and checking validity of types
 ✓ Collecting page data
 ✓ Generating static pages (8/8)
 ✓ Collecting build traces
 ✓ Finalizing page optimization

Route (app)                              Size     First Load JS
┌ ○ /                                    145 B           114 kB
├ ○ /_not-found                          977 B           115 kB
├ ○ /page1                               145 B           114 kB
├ ○ /page2                               145 B           114 kB
└ ○ /page3                               145 B           114 kB
+ First Load JS shared by all            114 kB
  ├ chunks/025f9754-472be801ff96a755.js  53 kB
  ├ chunks/301-7be2feb81c9932ce.js       59.1 kB
  └ other shared chunks (total)          1.89 kB


○  (Static)  prerendered as static content

So during next start, none of the Suspense fallbacks will show. Using export const dynamic = "force-dynamic"; will opt out of prerendering and will force the page to be dynamic at runtime, therefore showing the fallbacks.

What's curious is that in using useTimeout() (page 1) initially shows the page to be dynamic at next dev—not sure if that needs to be static at next dev to reflect what you'll see with next build.

On the latest canary, the new dev overlay lets you know whether a page will be prerendered statically, or if it's a dynamic page (Page 1 is dynamic in next dev).

The move towards dynamicIO I think makes this behavior a lot more simplified than what we currently have with Route Segment Config.

(screenshot reflects page 3 in next dev)

[CodingMeSwiftly]

Shouldn't suspense fallbacks be shown when the page is next visited after a revalidatePath? Because I see a different behaviour, where the suspense fallback is never shown for page that was initially statically rendered, even if the cache is invalidated with revalidatePath in a server action.