Repository navigation
App Router: OTel spans during cache component fallback resume reuse the trace id #1495
Description
This issue was created by an agent analysing CI failures from the Next.js Deploy Suite (vinext
mainvs Next.jsv16.2.6, 2026-05-22).
Problem
Spans created during fallback resume inside a Cache Component should have a fresh trace id distinct from the build-time render. vinext reuses the same trace id (e.g. 11989306), implying the span context is not being re-created per request resume.
Trace id reused across build-time render and runtime resume
Estimated Impact
~1 test failures across the deploy suite.
Affected Test Suites
test/e2e/app-dir/cache-components-allow-otel-spans/cache-components-allow-otel-spans.test.ts
Recommendation
-
Reproduce first in vinext's own test suite. Use the existing
cache-components-allow-otel-spansfixture and assert the trace id changes between build-time prerender and runtime resume. -
Reset the OTel context on resume. Each cache-component resume should start a new span/trace context, not inherit the prerender's.
Activity
james-elicx commentedon Jun 8, 2026
Triage update (agent investigation): this is blocked on the runtime cache-components fallback-resume serving path, not a localized OTel bug. vinext owns no runtime OTel tracer/span context (only
client-trace-metadataServer-Timing +navigation-trace), so the span-id reuse is a downstream symptom of the missing per-request dynamic resume render. The PPR fallback-shell machinery is currently build-time only (app-ppr-fallback-shell.ts/prerender-route-params.tsgated onVINEXT_PRERENDER=1), with runtime serving consumers explicitly deferred to #1715/#1716. Also not cheaply reproducible (needs a prod build + browser + OTLP collector, which the e2e harness lacks). Recommend deferring until #1715/#1716 land — fresh spans should follow naturally once fallback requests re-render dynamic params per request. Leaving open, blocked on #1715/#1716.fix(app-router): extend OTel tracer provider for Cache Component span…