nextjs - 💡(How to fix) Fix cacheComponents: true Server Actions on dynamic routes ([param]) return prerendered HTML shell (text/html) instead of RSC payload (text/x-component) in next start, causing "An unexpected response was received from the server" [1 comments, 2 participants]

Next.js: 16.2.x React: 19.2.0 Turbopack: enabled (default in 16) cacheComponents: true Deployment: Self-hosted (next start) — NOT Vercel

Describe the bug When cacheComponents: true is enabled and a Server Action is called from a dynamic route segment (e.g. /admin/curriculum/[courseId]), the server returns content-type: text/html with the prerendered PPR shell instead of content-type: text/x-component. This causes the Next.js client to throw: An unexpected response was received from the server.

This only happens when I build the project and run the production build locally.... It does NOT happen in: next dev Deployed to Vercel It works fine in dev mode and on vercel...

To Reproduce

Enable cacheComponents: true in next.config.ts Create a dynamic route: app/admin/[courseId]/page.tsx Place a Client Component on the page that calls a Server Action (e.g. a dialog that submits a form) Run next build && next start Trigger the Server Action Observe the POST request in DevTools response is text/html with x-nextjs-postponed: 1 and x-nextjs-prerender: 1 instead of text/x-component

Investigation findings After next build, the .next/server/app/admin/[courseId].html file is generated a prerendered PPR shell. When next start receives the Server Action POST to /admin/[courseId], instead of routing it to the action handler, it serves this prerendered shell, returning text/html. The response headers on the failing POST:

content-type: text/html; charset=utf-8
x-nextjs-postponed: 1
x-nextjs-prerender: 1
x-nextjs-stale-time: 300

The .meta file for the route contains a full postponed blob baked at build time. Key proof moving to a non-dynamic route fixes it: When the exact same page and Server Action are moved to simple route like this (e.g. app/admin/courses/page.tsx with no [param]), no .html file is generated in .next/server/app/admin/, and Server Actions work correctly. The issue is exclusively triggered by dynamic route segments with cacheComponents: true.

Attempted workarounds that did NOT fix it:

Adding await connection() from next/server at the top of the page the .html shell is still generated at build time and still served for POSTs Adding export const dynamic = "force-dynamic" incompatible with cacheComponents, throws a build warning and has no effect Adding Supabase data fetching (cookies(), headers()) directly in the page shell is still generated Deleting/bypassing the proxy (proxy.ts ) entirely no effect Adding generateStaticParams returning [] no effect

Attempted workaround that DID fix it (unacceptable for production):

Moving the page out of the dynamic route segment into a hardcoded path stopped the .html from being generated and Server Actions started working. This confirms the issue is specifically tied to dynamic route segments + cacheComponents PPR shell generation.

Root cause hypothesis With cacheComponents: true, PPR generates and stores a .html postponed shell for every dynamic route at build time. When next start receives a Server Action POST (identified by the next-action header), it appears to be incorrectly routing it through the PPR shell-serving path instead of the Server Action handler path.

Expected behavior A POST request with a next-action header to a PPR dynamic route should always be handled as a Server Action and return content-type: text/x-component, regardless of whether a prerendered shell exists for that route. Actual behavior The prerendered .html shell is returned with content-type: text/html, breaking the Server Action entirely.

What is the fix ? Is there a supported way to opt a specific dynamic route out of PPR shell generation with cacheComponents: true, so Server Actions on those routes work correctly in next start? If not, this appears to be a bug in how next start dispatches POST requests to PPR dynamic routes —the next-action header should take precedence over the PPR shell path.