Visiting the route in any real browser/device: the correct server-rendered content flashes on screen briefly, then the page crashes to Next's generic client-exception screen ("Application error: a client-side exception has occurred"). Browser console shows:
Uncaught Error: An error occurred in the Server Components render. The specific message is omitted in production builds to avoid leaking sensitive details. A digest property is included on this error instance which may provide additional details about the nature of the error. { digest: "1543818026" } (The digest is different on almost every occurrence, even for what should be the identical underlying error across repeated requests to the same URL.)
The exact same redacted line is the only thing that shows up in Vercel's Runtime Logs for the matching request — no fuller stack trace surfaces anywhere I can find on a Hobby plan.
What makes this route different from every other route in the app It's the only page that:
Has a dynamic segment ([id]) with no generateStaticParams — so it's genuinely server-rendered per request, not prerendered. Does a live database read (Supabase) directly in the Server Component at request time. Every other dynamic-segment page in the app (e.g. /moments/[id]) does use generateStaticParams, so its data-fetching/rendering only ever runs once at build time — and those pages have never shown this problem. Every static/non-dynamic page in the app also works fine.
What I've ruled out by direct production testing Not data-specific — reproduces on multiple different real rows, including a brand-new one created specifically to test this. Not caused by any component in the tree — reproduces even when the page is stripped down to: export default function Page() { return hello ; } with zero data fetching, zero client components, zero imports beyond React/Next itself. Not a third-party script/analytics SDK — we have one (loaded via instrumentation-client.ts, env-flag gated) and fully removing it (env var deleted, confirmed absent from network requests on a failing load) made no difference. Not route-segment config — reproduces with and without explicit dynamic, fetchCache, and maxDuration exports. Not generateMetadata — reproduces identically whether metadata is the async function form or a plain static export const metadata object. Not caching — X-Vercel-Cache: MISS and Cache-Control: private, no-cache, no-store on every request; the server-rendered body content correctly reflects each new deployment. Not a segment-file issue — confirmed no layout.tsx/template.tsx exists anywhere under this route besides the app's root layout (which is a plain, fully static component); confirmed the app's root-level opengraph-image.tsx does not cascade to this route (direct request to /c//opengraph-image returns a clean 404); no loading.tsx/icon.tsx/twitter-image.tsx for this segment. Not reproducible locally — neither next dev nor a real production build (next build && next start) against the same live database rows has ever reproduced this, across dozens of attempts. It only happens on the actual Vercel deployment. Not intermittent 503s on static chunks — saw the thread about _next/static/chunks/*.js intermittently 503ing and breaking hydration, which sounded like a strong candidate, so I checked it directly: every JS chunk this route loads (12 files) returned a clean 200 across 15 consecutive requests each (180 requests total, zero failures). What I can't do myself I don't have access to a non-redacted server-side stack trace for this digest, and I can't find any other segment file, config, or dependency that would explain a route-specific (not site-wide) failure that survives reducing the page to a hardcoded string.
Has anyone hit something like this — specifically tied to a route being the only fully dynamic, per-request-data-fetching page in a project deployed with Fluid Compute? Any pointers on where else to look, or how to get at the real error, would be hugely appreciated. Happy to share more detail (deployment IDs, additional digests, HAR files) if useful.
