Next.js 16.3 Preview — Feedback #95130

#95144 should address this

IIRC, there's a docs correction coming up. The cookies are, so called, session data, and can be included in the prefetched App Shell. The docs already contain this info, I think we just mixed up with a recent change.

Thanks for looking at this early on too! We'll have a proper preview release ceremony soon-ish.

Thanks, looking forward to the release

Also just realised that with prefetch prop on link, we don't prefetch runtime data. So in the case of a link to a route with no dynamic params (e.g. /), <Link href='/'> will prefetch the max amount of content possible (static shell + runtime content), but <Link href='/' prefetch> will prefetch less - which feels a bit odd!

@samselikoff is there any known timeline for this release? I know you guys are adding a lot of exciting new stuff but these CPU / memory fixes are really needed ASAP in my team, some idea of a timeline (even rough) would be nice!

The team is working to get a stable release out in the next few weeks. In the meantime, please keep reporting any issues you see in the preview.

Hi, thanks for giving this a go!

If I understand your description correctly, this is expected, and it is the kind of case Instant Insights helps developers with.

An /app/loading.tsx boundary does apply to the route tree below the root layout, that's correct. On a initial page load, you'd see the loading UI, given that there's uncached or runtime data in the destination page.

This is not the same for client navigations. On a client navigation, re-render doesn't necessarily happen from the root. It re-enters the tree at the shared layout boundary between the current route and the destination route. The root Suspense boundary be above that shared layout, and it is not used in that navigation.

That Instant Insight is letting you know that navigating into this route "blocks", because the route is likely accessing uncached data or runtime data access, and there's no the boundary in any of the shared layouts, to guarantee a instant UI. The dev overlay points exactly at what the issue is.

One possible fix is to Suspend there, but one could also use cache, it depends on your use case.

• https://preview.nextjs.org/docs/app/guides/instant-navigation#what-instant-means

I’m experiencing the same behavior.

This will be fixed by: #95315

This should be fixed in 16.3.0-canary.76.

Just tested this fix on stage. All good. Thanks!

What's the quickest way I could try to reproduce this? Do you already have a repository I could take a look at?

This could be caused by the preserved UI state though. Try this out: https://nextjs.org/docs/app/guides/preserving-ui-state#global-styles - it'd be nice to clear out the doubt, and land on a proper explanation for what you observed.

Did this ever go away? or maybe a Node.js version issue? I don't think I've seen this kind of a issue for a while now, since like 2023-ish.

This is a harmless (cosmetic) warning, not a bug in your code — and it's a known issue that the Next.js team is already tracking. You don't need to "fix" anything on your side. If it's noisy and you want it gone right now, add export const instant = false to the affected route.

Not sure if related, but I hit the same issue in a project that uses intercepted routes.

Minimal repro: https://github.com/apostolos/next.js-repro/tree/E1403-not-silenced
Diff: apostolos/next.js-repro@87f6134

Workaround is to add export const instant = false on default.tsx 🤷‍♂️

@aurorascharff @icyJoseph are you tracking this internally or should I open a new issue?

We do have a task for this - no need to open a further issue. Thanks for the report, a repro repository always helps a lot!

Here's some background on why this works the way it does today.

When you navigate to a page all page.tsx (or default.tsx) that match that page render. When you use parallel routes this means that blocking data in one slot can prevent the UI from another slot from rendering instantly. Because of this we validate the entire navigation, not just one slot at a time.

In many cases this is intuitive. However a few things make it very unintuitive in your reduced examples

1. The parallel slot isn't even actually rendered
2. The error message doesn't have a stack pointing to explicit validation opt in so we can't point you to the modal default.tsx as the UI that would be blocked by your await params (if it were rendered, which it isn't)

However fixing this is tricky because we don't want setting instant false on say a catchall parallel route to disable the insights for every other page that matches the current URL. This means we can't do something simple like say instant false overrides any implicit validation configuration.

Two ideas I am going to explore

1. Do not apply validation from slots that end up not being rendered. If a paralle route slot is defined in the project but isn't actually part of the current page's render then we can downgrade the implicit validation level. If only instant false remains we don't need to report anything as blocking
2. If however the parallel slot is rendered and would in fact be blocked by something inside and instant false tree we can augment the message to communicate which slot was blocked.

Adding instant = false to the parallel slot is actually the right move here, it's not really a work around per se. You are expressing that when this parallel slot does render we are ok with it being blocked too. However right now the error message doesn't help you understand this which leads to the current issues understandable confusion

Adding compress: false to next.config.ts reliably gets rid of this message.
I'm setting this for dev only.

The loading.tsx file is a convention for wrapping a route segment in a Suspense boundary. Before Cache Components, it also allowed Next.js to prefetch up to that boundary. But it was a blunt tool, and one that could be hard to place correctly.

With Cache Components, you can place a Suspense fallback anywhere in the component tree. The framework detects blocking work and only shows the fallback when that work is actually encountered. More importantly, it can tell you when navigated-to work would block, letting you decide whether to wrap it in a fallback, cache it, or explicitly allow and acknowledge the block.

So looking only at the difference between loading.tsx and Suspense is perhaps not the right way to frame it. The loading.tsx convention exists to wrap a segment in a Suspense boundary without forcing you to refactor your page into an intermediary component, such as BlogPage and BlogPageImpl, where the only reason for the split is to put Suspense around the place where params are accessed.

One of the biggest improvements is around “work that can be navigated into, but would block.” You can now wrap exactly that work, and no more, in a Suspense boundary. That lets you reveal more of the page sooner, instead of hiding an entire route segment behind a broader fallback.

This does not mean loading.tsx goes away. It just makes it a clear segment-level Suspense wrapping convention, rather than the main tool for deciding how much of a navigation should be revealed.

Which method did you use? Reading SST docs, there are two ways, OpenNext and Containers (Docker).

OpenNext

Alright, thanks, any more info? did you try disabling the experimental flags? OS? Node.js version? I guess os error 5 is from Windows? (gpt translation, Access is denied. (OS error 5))

os: windows 11, nodejs: v24.11.0(by volta);

ps: disabled all experimental flags

#95318 should add some more information here

After this error happens it would be useful to check permissions in the .next/dev/cache/turbopack directories and children to see what files exist and what there permissions are

This error shouldn't be fatal, it just disables persistence.

hit the same error as well with all experimental flags disabled except ViewTransition, (win11 26200.8655 node.js v24.18.0 managed by mise). The project files is on a dev drive by the way. The ACL results seems to be ok .

Access : BUILTIN\Administrators Allow  FullControl
         NT AUTHORITY\SYSTEM Allow  FullControl
         BUILTIN\Users Allow  ReadAndExecute, Synchronize
         NT AUTHORITY\SYSTEM Allow  268435456
         NT AUTHORITY\Authenticated Users Allow  Modify, Synchronize
         NT AUTHORITY\Authenticated Users Allow  -536805376
         BUILTIN\Users Allow  -1610612736

This was fixed by #95497 (tracked in #95495 )

syncing directories is important on posix filesystems but an error on windows (and apparently unnecessary).

This was released in 16.3.0-canary.79 and will be part of the 16.3 release

The Rust React Compiler is very new, and I think the whole JS/React ecosystem is figuring out how to integrate it.
The reason we were able to integrate it so easily into Turbopack is because we own the whole application, and we don't mind directly linking the code into our binary. It would be different to integrate the react compiler directly into SWC -- see, for example, oxc adding and then removing it recently.

SWC recently took ownership of the compiler crates that use it as the parser / transformer. They'll figure out the right way (direct integration vs plugins) to integrate it into projects that use SWC as a binary. I've personally compiled the React Compiler to a WASM plugin and it worked well, but it has a long cold startup time.
When they have a recommendation, we'll try to make it available to webpack Next.js users.

Thanks for the reminder, we'll look into it, we had started to look into it before. I'll post back with an update.

Hey @icyJoseph , Any update on the above issue ?

This landed in 16.3 — https://nextjs.org/blog/next-16-3

Thanks @icyJoseph Let me check if the issue is resolved. Thank you for looking into it.

I asked Fable 5, this is his response:

The issue

After migrating to Next.js 16, components rendered via the Storyblok (CMS) appear twice on the page. The first copy is dead, stale server HTML - not connected to React (invisible in React DevTools), not interactive. The second copy below it is the real, working component.

Next 16 made Turbopack the default bundler. Under Turbopack, the Pages Router never emits dynamicIds in NEXT_DATA, which is the mechanism that preloads next/dynamic({ ssr: true }) modules before hydration. All our components are registered through next/dynamic, so React hydrates before the component module is loaded, the client tree doesn't match the server HTML, and React abandons the server-rendered DOM - leaving the orphaned duplicate. Verified: server HTML contains the component exactly once; NEXT_DATA.dynamicIds is absent under Turbopack but present under --webpack, where the bug doesn't reproduce.

Why we can't fix it properly

This is an upstream Turbopack bug, not something in our code - any next/dynamic({ ssr: true }) component is affected. Reproduced on next@16.2.9 and the latest next@16.3.0-preview.5, so no available upgrade resolves it. Until Vercel emits dynamicIds (or equivalent preloading) for the Pages Router under Turbopack, the options are only workarounds: static imports (bundle-size cost), React.lazy + Suspense (bypasses Next's manifests), or building with --webpack.

Sounds like #77712

Yes I've seen this post too, 😞

Hoping this gets fixed 😅

Just to clarify — @VictorHaimov-HHH is it correct that this bug is specific to Pages router?

@gaearon , This issue happened when I used Pages Router , yes

An experimental flag to allow you to compile with typescript 7 has landed: #95639

The experimental.useTypeScriptCli option makes next build run the project-local tsc command instead of loading the TypeScript JavaScript compiler API. You can use this option with TypeScript 6, and it enables TypeScript 7 support while its JavaScript API is unavailable.

This experimental flag will first land in a canary, and should eventually make its way to either a preview drop, or next minor release.

it is available in the most recent preview https://x.com/timneutkens/status/2076771696745345363?s=20

I will be backporting support to 16.2 as well once the security release is out

#95318 did exactly this

@chungweileong94 Is this Bun-specific? Or you're not using Bun?

No, I'm not using bun. I'm facing this issue with NodeJS + Docker + standalone output.

Do you have a reproducing case?

The issue only happens on those packages that specified in serverExternalPackage.

Not sure how true is this, but I also noticed that if the external package is not being import within page or route, chances are the issue will happen. For instance, I was using @react-pdf/renderer(which part of serverExternalPackage by default) to render a pdf within an server function within a use server file, which is then import from a client component, it keeps hitting module not found on production build. But if I try to import from a page or route, the issue goes away.

Cool, I think I got a repro so we'll try to fix this

This was fixed by #95824, thanks for reporting

Hi! Any chance you could narrow this down to a sharable repro?

Hello. Heres the repo: https://github.com/pauksztello/nextjs-16.3-preview-issue

After some further testing, I couldn't reproduce the issue on my other two machines with this repo. The error only occurs on my macOS machine across all browsers. I also tried reproducing it on another Mac and a Windows PC without success. It might be an issue specific to my Mac. Does anyone have any advice on how to debug this? I'm a bit lost here.

Some additional findings:

1. next build --debug-prerender does not expand on error.
2. The error goes away when disabling partialPrefetching: true.

Appears to be fixed in preview.7

can you confirm that you are seeing this in production traffic not in local dev?

Are the actual requests themselves timing out or are downstream IO reporting timeout errors possibly due to improper cleanup.

The Typesense/PostgreSQL operation may already have started

this is true. you can preempt this work by putting await io() in front of it to allow the prerender to suspend there rather than where the downstream IO is happening.

Another thing to consider is in RSC you can access an AbortSignal that represents the render's lifetime by using import { cacheSignal } from 'react'. This signal will abort when the render is complete. you can pass it to fetch, or other native APIs that take AbortSIgnals or you can manually clean up any spawned work if no native consumer for the signal exists.

However, the 16.3 documentation says io() should not be necessary for awaited async database work already wrapped in Suspense.

Using IO isn't necessary for the correct semantics (native db queries won't be included in prerenders unless they are cached) but Suspense doesn't prevent the query from initiating. Next.js instruments fetch to it always has an implicit await io() inside of it so to speak, but for native IO Next.js can't do this so as a performance optimization you can preempt your native io with this shield function

Yes, this is happening with production traffic on Vercel, not in local development.

I haven’t confirmed that user navigation requests themselves wait until the timeout. What I can confirm is that downstream native I/O operations continue until their own timeouts, despite no increase in request volume for either Typesense or PostgreSQL.

I added await io() immediately before every Typesense client operation and its PostgreSQL enrichment query. That completely stopped the Typesense timeouts. However, another unrelated PostgreSQL query elsewhere in the rendered tree is now failing:

EAUTHTIMEOUT: timeout while waiting for message
code: 08006
severity_local: FATAL

This is a normally fast indexed user lookup. Unlike the previous PostgreSQL statement_timeout, this failure occurs while Postgres.js is waiting for the authentication handshake to complete.

This makes the behavior look broader than a Typesense-specific problem: native I/O initiated during speculative rendering can apparently remain alive or stalled when that render is abandoned. Adding io() fixes each operation individually, but then the same symptom appears at the next unshielded database access.

I understand now that Suspense only catches the pending result after the operation has already started. Still, I find this frustrating from an application-development perspective. Adding await io() before every native database or SDK operation throughout an existing application is substantial complexity and feels very easy to miss. Disabling prefetching avoids the issue, but that is not an acceptable solution for us because prefetching makes the website noticeably faster.

Ideally, reaching a Suspense boundary during speculative rendering would stop before executing its dynamic subtree, or there would be a route/subtree-level mechanism to shield all native I/O below it. Is there a recommended way to achieve that without annotating every individual query?

You can make your own "don't render this Suspense" component if you want to however it is intentional that Suspense does not automatically halt prerendering because there are various kinds of prerendering that Next.js can do. For instance with partial prefetching we can render through say a cookies() await but won't progress past a await params when prefetching a route shell. If we always just suspended at every Suspense you couldn't compose your app to have different representations depending on the prerendering context.

async function SuspendDuringPrerender({ fallbabck, children }) {
  return (
    <Suspense fallback={fallback} >
      {io()}
      {children}
    </Suspense>
  )
}

This function will always render the fallback during any prerender unless it is inside a "use cache" scope since io() always suspends during a prerender.

Now back to your actual issue, can you share more about your postgres setup? is a hosted postgres instance? what sdk are you using to connect to it?

The fact that the auth is timing out suggests to me that

1. it is using fetch() to do the auth (hence why it is hanging on prerender
2. it is not getting cleaned up as expected when the prerender aborts (implies a bug in Next.js) OR it is getting cleaned up but the postgres client doesn't get the memo so it doesn't abort eagerly

Postgres is hosted on Supabase and connecting via IPv4 transaction pooler with Drizzle.

packages/db/src/index.ts

import { drizzle } from "drizzle-orm/postgres-js";
import postgres from "postgres";
import { env } from "./env";
import { relations } from "./relations";

export const db = drizzle({
  client: postgres(env.POSTGRES_URL, { prepare: false }),
  relations,
});

Hi @jperezrealini sorry for the silence but I have been pulling on this thread off and on.

So the problem that you are experiencing is I believe a consequence of how OS-level IO is handled in lambda. Lambda will freeze vms and restore them and so anything like raw TCP can get paused and then resumed in ways that upstream systems can't reason about well and I suspect that is leading to the timeout errors you are observing.

This is a longstanding problem with lambda in general however it is made worse by Cache Components in that the places where this was a problem historically were more overt (you wrote code intentionally to be non-blocking IO but you still wanted it to complete, say telemetry post-render). With CC the non-blocking IO is coming from a special kind of render and your code is written in a way that ideally doesn't have to consider this.

What I'd like you to do if you're willing is to configure your vercel functions to use extended max duration beta to opt into Vercel's new microVM-based architecture. Anything over 800s should do the trick: https://vercel.com/changelog/vercel-functions-can-now-run-up-to-30-minutes

I am expecting that these timeouts will just go away if you do this. If they do not that's definitely useful info and I'd like to continue digging here.

Eventually the new architecture will be running all workloads so you won't have to opt int specifically but I don't have details on any kind of timeline for that.

Thanks

If you downgrade to 16.3.0-preview.6 do these errors go away? can you also try clearing out the .next folder in your project when on .7 and try again?

If you downgrade to 16.3.0-preview.6 do these errors go away? can you also try clearing out the .next folder in your project when on .7 and try again?

Yeah, tried both. If I downgrade to preview.6, these errors go away. Even if I remove the .next folder with .7, the errors will happen again.

We ran into a similar issue. This has been fixed by #96028. We'll get a new preview out with that fix soon.

Really appreciate that🙏