feat(node): Wire up SentryTracerProvider#21680
Draft
andreiborza wants to merge 11 commits into
Draft
Conversation
andreiborza
requested review from
JPeer264 and
mydea
and removed request for
a team
Contributor
size-limit report 📦
|
andreiborza
changed the title
andreiborza
force-pushed
the
ab/sentry-trace-provider-node
branch
from
e05567e to
dc3cd9d
Compare
andreiborza
force-pushed
the
ab/sentry-trace-provider-otel
branch
from
7f2f88d to
172dd9f
Compare
andreiborza
force-pushed
the
ab/sentry-trace-provider-node
branch
from
dc3cd9d to
f3c0c65
Compare
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
nicohrubec
reviewed
Jun 22, 2026
| coreDebug.warn( | ||
| 'Could not register SentryTracerProvider because another OpenTelemetry tracer provider is already registered.', | ||
| ); | ||
| return [undefined, undefined]; |
Member
There was a problem hiding this comment.
m: is this in a good state if the setup fails here? we won't install the sentry propagator and context manager in here and then we also bail early in the main setupOtel method but we already set up the otel async context strategy. might be fine just checking
Member
Author
There was a problem hiding this comment.
There is no good state if the tracer provider registration fails users won't get proper traces, but there's no way to recover from this because you can only ever register one global tracer provider and if one is already registered you can't do anything.
That's why we log here, I think it's fine as is.
| ): [BasicTracerProvider, AsyncLocalStorageLookup] { | ||
| ): [OpenTelemetryTraceProvider | undefined, AsyncLocalStorageLookup | undefined] { | ||
| if (client.getOptions()._experiments?.useSentryTracerProvider) { | ||
| setOpenTelemetryContextAsyncContextStrategy(); |
Member
There was a problem hiding this comment.
m: do we even need to call this here? setupOtel is called from initOpenTelemetry, which is called in the node init after we make the node-core init which also makes this same call:
andreiborza
force-pushed
the
ab/sentry-trace-provider-otel
branch
from
172dd9f to
afb77ef
Compare
andreiborza
force-pushed
the
ab/sentry-trace-provider-node
branch
from
e200c8f to
502dca9
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
andreiborza
force-pushed
the
ab/sentry-trace-provider-otel
branch
from
afb77ef to
fcdf2df
Compare
andreiborza
force-pushed
the
ab/sentry-trace-provider-node
branch
from
502dca9 to
6ae8302
Compare
andreiborza
force-pushed
the
ab/sentry-trace-provider-otel
branch
2 times, most recently
from
2c670f3 to
308e560
Compare
andreiborza
force-pushed
the
ab/sentry-trace-provider-node
branch
from
6ae8302 to
e2f91c0
Compare
andreiborza
force-pushed
the
ab/sentry-trace-provider-node
branch
2 times, most recently
from
4a3010c to
d2384e8
Compare
mydea
reviewed
Jun 23, 2026
| * @default false | ||
| * @experimental | ||
| */ | ||
| useSentryTracerProvider?: boolean; |
Member
There was a problem hiding this comment.
should this live in core? is this not a node-specific option?
Member
There was a problem hiding this comment.
also, why experimental? this can just be a regular option, and as discussed I'd actually make it opt-out (or more specifically, make the default dynamic based on if any options are set that require the more fully features tracer, e.g. spanProcessors)
Member
There was a problem hiding this comment.
Wouldn't this be a breaking change? I thought the opt-out would be rather for v11 and in v10 it's opt-in
andreiborza
force-pushed
the
ab/sentry-trace-provider-otel
branch
2 times, most recently
from
cc82764 to
400be89
Compare
andreiborza
force-pushed
the
ab/sentry-trace-provider-node
branch
from
06f6f64 to
6759aa8
Compare
andreiborza
requested review from
Lms24,
logaretm and
mydea
and removed request for
a team
andreiborza
force-pushed
the
ab/sentry-trace-provider-otel
branch
from
400be89 to
0cb493b
Compare
andreiborza
force-pushed
the
ab/sentry-trace-provider-node
branch
3 times, most recently
from
65315bf to
94c9cfd
Compare
Lms24
reviewed
Jun 24, 2026
| }); | ||
|
|
||
| client.on('preprocessEvent', event => { | ||
| if (event.type !== 'transaction' || client.getOptions().traceLifecycle === 'stream') { |
Member
There was a problem hiding this comment.
l: event processors aren't called for streamed spans, so no need to check here (unless I'm missing something 😅)
Suggested change
| if (event.type !== 'transaction' || client.getOptions().traceLifecycle === 'stream') { | |
| if (event.type !== 'transaction') { |
Member
Author
There was a problem hiding this comment.
Right, removed! Turns out we don't backfill these otel resources in span streaming but that's probably fine. We are thinking of going away from them completely in v11. TBD.
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.
Reviewed by Cursor Bugbot for commit 2db451e. Configure here.
andreiborza
force-pushed
the
ab/sentry-trace-provider-node
branch
from
2db451e to
96e1f2e
Compare
andreiborza
force-pushed
the
ab/sentry-trace-provider-otel
branch
from
babe9a6 to
71ecd8d
Compare
andreiborza
force-pushed
the
ab/sentry-trace-provider-node
branch
3 times, most recently
from
58c53f4 to
1e0d83e
Compare
Add the SentryTracerProvider under an experimental `useSentryTracerProvider` flag and update the node setup path to register the new TracerProvider and its async context strategy instead of the full OTel SDK tracer provider when enabled.
Outside of span streaming, an outgoing fetch (`http.client`) span with no local parent is no longer recorded as a standalone transaction — the downstream sampling decision is left to the server. This is enforced via `onlyIfParent`, which still creates a non-recording span so trace propagation headers are injected. This rule already lives in `SentrySampler`, but that only runs when an OpenTelemetry SDK tracer provider is set up. Enforcing it in the instrumentation makes it hold for the `SentryTracerProvider` and for SDKs that don't use an OpenTelemetry tracer provider at all. The sampler rule is kept for OpenTelemetry SDK / custom OpenTelemetry setups.
andreiborza
force-pushed
the
ab/sentry-trace-provider-node
branch
from
1e0d83e to
8aeffe4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Wires up the node SDK to use
SentryTracerProviderwhen_experiments.useSentryTracerProvideris enabled (default opt-in).When enabled, it uses our SentryTracerProvider and async context strategy instead of the Otel SDK's.
For simplicity, a flag is used, but we could change this to be an explicit call (+ a flag to opt out of the current tracer provider) to save some bundle size.