Background
Split out from #2399.
The OpenTelemetry SentrySpanProcessor currently sets Scope.Transaction unconditionally when it starts a new (root) transaction:
https://github.com/getsentry/sentry-dotnet/blob/main/src/Sentry.OpenTelemetry/SentrySpanProcessor.cs#L175
This is guarded by the parent-span logic above it (a new transaction is only started when the activity has no parent span we already track):
|
if (data.ParentSpanId != default && _map.TryGetValue(data.ParentSpanId, out var mappedParent)) |
|
{ |
|
// Explicit ParentSpanId of another activity that we have already mapped |
|
CreateChildSpan(data, mappedParent, data.ParentSpanId); |
|
} |
|
// Note if the current span on the hub is OTel instrumented and is not the parent of `data` then this may be |
|
// intentional (see https://opentelemetry.io/docs/languages/net/instrumentation/#creating-new-root-activities) |
|
// so we explicitly exclude OTel instrumented spans from the following check. |
|
// of Sentry |
|
else if (_hub.GetSpan() is IBaseTracer { IsOtelInstrumenter: false } inferredParent) |
|
{ |
|
// When mixing Sentry and OTel instrumentation and we infer that the currently active span is the parent. |
|
var inferredParentSpan = (ISpan)inferredParent; |
|
CreateChildSpan(data, inferredParentSpan, inferredParentSpan.SpanId); |
|
} |
|
else |
|
{ |
|
CreateRootSpan(data); |
|
} |
So in practice this only overwrites an existing Scope.Transaction in the edge case where there is already an OTEL transaction on the scope and the current span doesn't have that transaction as its parent.
Proposal
In that edge case, the processor should only set Scope.Transaction when it is currently null, rather than overwriting whatever is already there. There's no perfect answer here (it depends on what the user intends, which we don't have enough context to know), but not overwriting an existing transaction is the more intuitive default.
Notes
Background
Split out from #2399.
The OpenTelemetry
SentrySpanProcessorcurrently setsScope.Transactionunconditionally when it starts a new (root) transaction:https://github.com/getsentry/sentry-dotnet/blob/main/src/Sentry.OpenTelemetry/SentrySpanProcessor.cs#L175
This is guarded by the parent-span logic above it (a new transaction is only started when the activity has no parent span we already track):
sentry-dotnet/src/Sentry.OpenTelemetry/SentrySpanProcessor.cs
Lines 96 to 114 in 14c1d8c
So in practice this only overwrites an existing
Scope.Transactionin the edge case where there is already an OTEL transaction on the scope and the current span doesn't have that transaction as its parent.Proposal
In that edge case, the processor should only set
Scope.Transactionwhen it is currentlynull, rather than overwriting whatever is already there. There's no perfect answer here (it depends on what the user intends, which we don't have enough context to know), but not overwriting an existing transaction is the more intuitive default.Notes
SentryOptions.AutoSetScopeTransactions) so it can be evaluated independently.