feat: Tracing without performance #2493
Conversation
Instructions and example for changelogPlease add an entry to Example: ## Unreleased
- Tracing without performance ([#2493](https://github.com/getsentry/sentry-dotnet/pull/2493))If none of the above apply, you can opt out of this check by adding |
Co-authored-by: James Crosswell <jamescrosswell@users.noreply.github.com>
There was a problem hiding this comment.
I didn't do a full review - just the files that have changed since I last checked a few days ago. All looking good.
My only question is what we plan to do with the EnableTracing option.
Otherwise, once the Check failures from CI are addressed, I think it's looking good.
| string? operation = null) | ||
| { | ||
| // Transactions from DisabledHub are always sampled out | ||
| return new TransactionContext(string.Empty, string.Empty, false); |
There was a problem hiding this comment.
I think we could do the same thing we've done for the DisabledHub.Instance here, to avoid creating a new object every time this method is called.
Not sure where to put that... maybe TransactionContext.Disabled or TransactionContext.DisabledInstance?
|
A bit annoying, but you have to run a build on a Windows box to get the verify tests running (and the file you need to commit) to fix this:
|
Resolves #2447
Implementations in other SDKs:
The idea here is:
The scope now has a
SentryPropagationContext. The context contains minimally atraceIDand aspanID.ContinueTraceoverwrites the context on the current scope, making it possible to propagate the IDs without the performance feature enabled.Relevant top-level methods:
GetTraceHeader,GetBaggage. The methods first look for active spans before falling back to creating their return value from the PropagationContext. The same is true forCaptureEventwhere we check for linked or active spans first.