App Router: OTel spans during cache component fallback resume reuse the trace id

[james-elicx]

This issue was created by an agent analysing CI failures from the Next.js Deploy Suite (vinext main vs Next.js v16.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

1. Reproduce first in vinext's own test suite. Use the existing cache-components-allow-otel-spans fixture and assert the trace id changes between build-time prerender and runtime resume.

2. Reset the OTel context on resume. Each cache-component resume should start a new span/trace context, not inherit the prerender's.

[james-elicx]

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-metadata Server-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.ts gated on VINEXT_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.