Description
Today, if you do not enable tracing in Sentry at all, but use a custom OTEL setup, any calls of Sentry.startSpan() will emit spans into your custom otel setup.
While for users this is likely not super relevant, there is always the possibility for calls to our span APIs in our own code to leak like this, which is not really expected. So to avoid this, we should likely ensure to return a non recording span instead in these cases and not actually record a span.
NOTE: We should not use suppressTracing() for this as this would also suppress tracing inside of the callback. We may use suppress tracing in a nested way (?) possibly, but this could become a bit tricky:
const wasSuppressed = isTracingSuppressed(ctx);
const newCtx = wasSuppressed ? ctx : suppressTracing(ctx);
return context.with(newCtx, () => {
return tracer.startSpan(..., () => {
return context.with(ctx, () => {
return callback();
})
})something along these lines!
Description
Today, if you do not enable tracing in Sentry at all, but use a custom OTEL setup, any calls of
Sentry.startSpan()will emit spans into your custom otel setup.While for users this is likely not super relevant, there is always the possibility for calls to our span APIs in our own code to leak like this, which is not really expected. So to avoid this, we should likely ensure to return a non recording span instead in these cases and not actually record a span.
NOTE: We should not use
suppressTracing()for this as this would also suppress tracing inside of the callback. We may use suppress tracing in a nested way (?) possibly, but this could become a bit tricky:something along these lines!