Unify tracePropagation vs propagateTrace option names #23571
Description
Follow-up from #23443 (Isaac's review).
httpIntegration now exposes tracePropagation, matching Deno and nativeNodeFetchIntegration. Core's HttpInstrumentationOptions and Node's outgoing instrumentation still use propagateTrace. The Node integration maps between them:
propagateTrace: options.tracePropagation ?? true,Goal
Pick one name and use it end-to-end (public integration options + core HttpInstrumentationOptions + Node outgoing instrumentation).
Recommendation
Keep tracePropagation as the public name — Deno and node-fetch already use it, and it sits next to tracePropagationTargets. Rename core/internal propagateTrace to match, rather than renaming the public option back to propagateTrace.
Do not conflate this with propagateTraceparent (W3C traceparent header) or tracePropagationTargets (which URLs get headers).
Scope
packages/core/src/integrations/http/types.ts(propagateTrace)- Node
httpIntegration/OutgoingHttpRequestInstrumentationOptions - Deno
httpIntegration(alreadytracePropagationpublicly; still maps topropagateTrace) - Call sites in
client-subscriptions,client-patch, tests, docs
This is a breaking change if we rename either exported option, so it belongs in 11.0 rather than a later minor.
Out of scope
propagateTraceparent and tracePropagationTargets stay as they are.
Activity
linear-code commentedon Aug 25, 2026
JS-3427
ref(core)!: Unify `tracePropagation` vs `propagateTrace` option names (…
github-actions commentedon Sep 23, 2026
A PR closing this issue has just been released 🚀
This issue was referenced by PR #23649, which was included in the 11.0.0 release.