Client decision rule for trace meta tags under cacheComponents #24944

The server tells the browser which trace it belongs to through a <meta name="sentry-trace"> tag. Under cacheComponents the shell of a document is prerendered and cached, so a tag baked into it would be replayed to every later visitor. Until now the SDK avoided that by not emitting tags at all, so pageloads and server requests were never connected.

Changes

• Server: a Next.js-aware propagator (NextSentryPropagator) hands out no sentry-trace/baggage while a prerender route (app) span is active. A prerendered shell, at build time or at request time, never carries a trace. Next.js computes the tags inside that span for prerenders and outside of it for request renders, including the resume of a shell. Verified for Next.js 15.0 through 16.3.
• Config: experimental.clientTraceMetadata is enabled again under cacheComponents.
• Client: any tag in the document is continued, the last one wins. Blocking pages (export const instant = false) and dev mode join the server trace right away, no special case.
• Client: when no tag and no Server-Timing trace are present and the document is still streaming, the pageload span waits for the resumed part, bounded by DOMContentLoaded and a 10 s cap, then continues the server trace. Start timestamp stays at the time origin, children come from the performance timeline, so the span looks the same as before.
• Client: a navigation during that wait starts the pageload with a fresh trace before the navigation span is created, so it becomes the pageload's redirect child instead of the only record of the visit.
• Removed: the generateStaticParams based meta tag removal (removeIsrSsgTraceMetaTags) and the isrRoutes manifest field. ISR shells are prerenders, so the server guard covers them, including revalidate routes without generateStaticParams.

Not done, deliberately

• No cache_origin links from meta tags. Shells are trace-free, so a visitor of a cached shell starts a fresh trace with nothing to link. The use cache instrumentation keeps its own cache_origin links.
• Fetches and errors between SDK start and the arrival of the resumed part are not attached to the pageload. That window is the dynamic hole's render time, longer on Vercel where the CDN serves the shell before the function starts. The Server-Timing sub-issues close it.

Verified

• Unit tests in packages/nextjs.
• E2E in both cacheComponents apps, production and development: /pageload-tracing joined, /blocking joined, two visitors of a shell generated at request time never share a trace and carry no links, fully static page starts fresh.
• E2E nextjs-16 including the ISR pages, which now rely on the server guard.
• Real telemetry from a demo app: every /pageload-tracing and /blocking pageload shares a trace with its server request, no trace holds two pageloads.