WIP feat(opentelemetry): Add SentryTraceProvider#21181
Conversation
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
size-limit report 📦
|
andreiborza
force-pushed
the
ab/sentry-tracer-provider
branch
from
0f2020a to
71e7c69
Compare
| */ | ||
| public recordException(_exception: unknown, _time?: number | undefined): void { | ||
| // noop | ||
| public recordException(exception: unknown, time?: SpanTimeInput | undefined): void { |
There was a problem hiding this comment.
I think we can leave this as noop, we do not care about this and do not really support it, doing nothing with events etc.
andreiborza
force-pushed
the
ab/sentry-tracer-provider
branch
from
71e7c69 to
a44215e
Compare
andreiborza
force-pushed
the
ab/sentry-tracer-provider
branch
from
cf369b6 to
749e7e7
Compare
andreiborza
force-pushed
the
ab/sentry-tracer-provider
branch
6 times, most recently
from
8ebaf6b to
2b70730
Compare
andreiborza
force-pushed
the
ab/sentry-tracer-provider
branch
from
959483b to
87ed1f0
Compare
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 5917bab. Configure here.
andreiborza
force-pushed
the
ab/sentry-tracer-provider
branch
3 times, most recently
from
d265e00 to
34725df
Compare
`SentrySpan.updateName()` stamps `sentry.source: 'custom'` unconditionally again (as on develop), except for spans branded via `markSpanForOtelSourceInference()`. SentryTraceProvider sets that brand on the spans it creates, so instrumentations renaming them don't pin 'custom' and `applyOtelSpanData` can infer the correct source (e.g. 'route', 'task') at span end — mirroring OTel SDK spans, which carry no Sentry source concept. This replaces the earlier "only set custom when a source already exists" heuristic, which also unintentionally stopped stamping 'custom' on user-created child spans that start without a source. Branding scopes the carve-out to exactly the provider-created spans. Standalone this commit is develop-equivalent (nothing sets the brand yet); the follow-up SentryTraceProvider PR flips it on. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add a minimal OpenTelemetry `TracerProvider` that creates native Sentry spans instead of bridging through the full OTel SDK. Includes the `SentryTracer`, `applyOtelSpanData` OTel-to-Sentry inference, sampling-decision propagation via the span context, and supporting changes to the async context strategy, setup checks, and DSC/root-span-name enhancement. Exposed for wiring via `_INTERNAL_startInactiveSpan` in core. Gated behind the consumer SDK and has no effect until enabled there. Co-Authored-By: Claude <noreply@anthropic.com>
Add the `useSentryTraceProvider` experimental option and the Node setup path that registers the `SentryTraceProvider` (and its async context strategy) instead of the full OpenTelemetry SDK tracer provider when enabled. Skips the `SentrySpanProcessor`/`SentrySampler` setup that the provider replaces, guards the HTTP server-spans integration for the missing async-local-storage lookup, and finalizes span data on `spanEnd`. Defaults to off. Co-Authored-By: Claude <noreply@anthropic.com>
andreiborza
force-pushed
the
ab/sentry-tracer-provider
branch
from
916e70a to
a6caf6a
Compare
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…eeded Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
isaacs
left a comment
isaacs
left a comment
There was a problem hiding this comment.
Some comments, mostly in the nitpick/bikeshed category, but a few that might be worth at least verifying aren't a concern before landing.
| const LEGACY_HTTP_RESPONSE_STATUS_CODE_ATTRIBUTE = 'http.status_code'; | ||
| const RPC_GRPC_STATUS_CODE_ATTRIBUTE = 'rpc.grpc.status_code'; | ||
|
|
||
| const VALID_SPAN_STATUS_MESSAGES = new Set([ |
There was a problem hiding this comment.
This could be somewhat minor, but it seems like this is duplicated with the same values in packages/opentelemetry/src/utils/mapStatus.ts. Would be nice to have a single source of truth. (Though, I suppose they're not likely to change, so maybe a non-issue.)
| /** | ||
| * A minimal OpenTelemetry TracerProvider which creates native Sentry spans. | ||
| */ | ||
| export class SentryTraceProvider implements TracerProvider { |
There was a problem hiding this comment.
Minor nit, but SentryTraceProvider vs otel's naming TracerProvider, could cause confusion? Autocomplete mostly protects us, and I imagine it's unlikely that anyone who isn't writing an SDK will be using this, but could be less confusing if named SentryTracerProvider.
Ie, it seems like what it's providing are SentryTracer objects, not "traces", so it's a "tracer provider", not a "trace provider". (This is extremely bikesheddy, I do realize.)
| 'http.status_text': statusMessage?.toUpperCase(), | ||
| }; | ||
|
|
||
| const rpcMetadata = getRPCMetadata(context.active()); |
There was a problem hiding this comment.
Doesn't this mean that if someone changes the RPCMetadata between the request and response, it won't be picked up? I'm imagining if a web framework updates the route at some point, or something like that.
| } | ||
|
|
||
| /** Apply OTel semantic inference to a Sentry span. */ | ||
| export function applyOtelSpanData(span: Span, options: { finalizeStatus?: boolean } = {}): void { |
There was a problem hiding this comment.
It looks like this method gets called twice per span, once at the span start, and then again on spanEnd. Since it does a full spanToJSON, I worry that the serialization overhead could get expensive.
Is it possible to either defer the whole thing until the span ends, or just do the necessary finalization at the end without computing all the data all over again? Presumably it won't often change, right?
| /** @inheritdoc */ | ||
| public getTracer(name: string, version?: string, options?: TracerOptions): Tracer { | ||
| const key = JSON.stringify([name, version, options]); | ||
| const cachedTracer = this._tracers.get(key); |
There was a problem hiding this comment.
It looks like SentryTracer is a just stateless "bag o' methods" object, so any tracer is equivalent to any other. Are we using them as keys in a map or something, that would require that they be unique per name/version/options? If not, maybe we could skip the cache, and just have a single instance?
Possible this will be needed in the future use case, and I'm just not seeing it because it's not in this PR, if so, disregard. But in that case, we might want to consider making this an LRU or setting some upper bound, just for safety's sake, so it doesn't blow up and become a memory leak.
| @@ -0,0 +1,356 @@ | |||
| /* eslint-disable max-lines */ | |||
There was a problem hiding this comment.
Oh, also, if those repeated consts (VALID_SPAN_STATUS_MESSAGES et al) are moved out into a shared location, probably don't need this override ;)
|
This PR is superseded by #21666. |
3 participants
WIP