Uh oh!
There was an error while loading. Please reload this page.
feat(opentelemetry)!: Simplify propagation and remove custom OTel tracing utils - #22702
Conversation
size-limit report 📦
|
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
c4a4b13 to
93d6542CompareUh oh!
There was an error while loading. Please reload this page.
afdbe2c to
7aa618cCompare| scope.setPropagationContext({ | ||
| traceId: generateTraceId(), | ||
| sampleRand: safeMathRandom(), | ||
| return withActiveSpan(null, () => { |
There was a problem hiding this comment.
just switching this up, it should not make concrete difference but seems more resilient, as it makes us more independent of what withActiveSpan does under the hood!
| } | ||
| /** Custom implementation for OTEL, so we can handle scope-span linking. */ | ||
| protected _getTraceInfoFromScope( |
There was a problem hiding this comment.
it seems this was not used anywhere anymore!
SentryPropagatorUh oh!
There was an error while loading. Please reload this page.
remove getTraceData & fixes fix traceparent propagation
cf12656 to
5d24bc4CompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
# Conflicts: # packages/core/src/monitor.ts # packages/core/test/integrations/redis/redis-common.test.ts # packages/node/test/integrations/tracing/redis/redis-common.test.ts # packages/opentelemetry/src/asyncContextStrategy.ts # packages/server-utils/src/async-context.ts # packages/server-utils/test/async-context.test.ts # packages/server-utils/test/redis/redis-common.test.ts # packages/vercel-edge/test/middlewareTraceIsolation.test.ts
Co-authored-by: Sigrid <32902192+s1gr1d@users.noreply.github.com>
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 61517d1. Configure here.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.

Simplifies the OpenTelemetry
SentryPropagatordown to a thinTextMapPropagatorthat delegates all trace-data serialization to core'sgetTraceData(), and removes the custom OTel-specific tracing/propagation overrides (continueTrace,startNewTrace,getTraceData,getTraceContextForScope) in favor of core's implementations. The net effect is that OTel-powered SDKs (Node, Next.js, SvelteKit, etc.) now share the same propagation and trace-continuation code paths as the rest of the SDK instead of maintaining a parallel OTel-only variant.What changed
SentryPropagatorno longer extendsW3CBaggagePropagator. It now implementsTextMapPropagatordirectly.inject()reads headers fromgetTraceData()and only operates on the active context — if called with a non-active context it warns and skips.tracePropagationTargetsfiltering andpropagateTraceparentare no longer the propagator's concern — outgoing-request filtering already lives in the Node HTTP layer (inject-trace-propagation-headers.ts), so the duplicated logic, the_urlMatchesTargetsMapLRU cache, and thesentry.urltrace-state (SENTRY_TRACE_STATE_URL) are removed.getTraceData,continueTrace, andstartNewTraceoverrides from the async context strategy. Core's implementations are now used directly. To make this work,continueTrace/startNewTracein core were reworked to route throughwithActiveSpan(null, …), and OTel's non-recording (TwP) spans fall back to the scope's propagation-context trace id.getTraceContextForScope(andNodeClient._getTraceInfoFromScope); scope→trace-context resolution now goes through the shared core path._startSpannow runs the callback with the started span set active on the unsuppressed context, fixing event trace-context attaching to a stale ancestor span acrossstartNewTrace/continueTraceboundaries.Aligning Node and Browser behavior
Previously, the OTel/Node path and the browser (core) path had subtly diverging propagation behavior because they ran through different implementations of
getTraceData,continueTrace, andstartNewTrace. The OTel variants derived trace data from the OTel context/span graph, while the browser used core's scope- and span-based logic — so edge cases (TwP sampling, DSC freezing, which trace id a fresh root span lands on) could resolve differently between the two.By deleting the OTel-specific overrides and routing everything through core, Node and Browser now produce trace headers and continue/start traces via a single common code path. There is one source of truth for how a
sentry-trace/baggagepair is derived from the current scope and span, which removes a class of Node-vs-Browser discrepancies and makes future changes apply uniformly to both.Test adjustments
Because this aligns Node's propagation/trace-continuation behavior with the common core path, a number of Node integration tests had to be updated to match the new (now shared) behavior — primarily expectations around trace ids for parallel/root spans and outgoing-request propagation (
parallel-root-spans,parallel-spans-in-scope,fetch-sampled-no-active-span, etc.). These changes reflect the corrected/unified behavior, not regressions.Breaking changes
getTraceContextForScopeis no longer exported from@sentry/opentelemetry.sentry.urltrace-state and thegetInjectionData/ OTel-specificgetTraceDatainternals of the propagator are removed.SentryPropagatorno longer injects when called with a non-active context.Closes#22281