Performance: SDKs sending transactions despite tracing being disabled

[rhcarvalho]

If the user has set the TracesSampleRate to 0 to disable it and hasn't set TracesSampler to anything, then their web app may still be starting and sending transactions if it receives an incoming HTTP request with a Sentry trace header. At least that's how it works in ASP.NET Core right now. Is this a desired behavior?

Originally posted by @Tyrrrz in https://github.com/getsentry/develop/issues/264#issuecomment-776957605

[rhcarvalho]

If the user has set the TracesSampleRate to 0 to disable it and hasn't set TracesSampler to anything,

This is, today, synonym with having tracing disabled and is the default. (We say that tracing is enabled when either TracesSampleRate > 0 or TracesSampler != null)

At least that's how it works in ASP.NET Core right now.

FWIW this is also how it works in Python.

Is this a desired behavior?

There has been some discussions about it (cc @lobsterkatie). On one hand it might be surprising behavior. On the other hand we've exploited this behavior in Python for some time now in Sentry.io itself.

We've considered having yet-another-field for explicit enablement but that's also a cumbersome path, as it would require more config to enable tracing.

My current thought is that this is surprising behavior and thus not desired. Users must set either a non-zero sample rate or a non-null traces sampler to communicate that the SDK should capture and send transactions.

Open to hear other people's thoughts on this so we can document a conclusion.

[marandaneto]

I agree with @rhcarvalho here.

Spring boot also has a dedicated flag and I'm not happy with it, actually, we already got an issue about that (eg: I enabled the boolean and it's still not working due to missing the tracesSampleRate)

https://docs.sentry.io/platforms/java/guides/spring-boot/performance/#enable-tracing

[rhcarvalho]

The reason there has not been such flag is indeed what you describe, @marandaneto. Since we introduced tracing as opt-in, and at the time there was only tracesSampleRate, it made no sense to require both a flag=true and a rate > 0, it was redundant.

[Tyrrrz]

One option is to add a shouldContinueFromTrace flag that has 3 states (yes, no, undefined). If it's undefined, we continue only if the rate is configured > 0. Otherwise it either always works or always doesn't.

[lobsterkatie]

The way it works in Python and Javascript is that if either traces_sample_rate or traces_sampler is set, tracing is enabled (even if the former is set to 0). If neither is set, tracing is disabled. (Both options default to None/undefined if not set.)

This to me seems like the desired behavior - it allows for the use case of tracing only when an upstream service requests it via the sentry-trace header (using traces_sampler), doesn't force users to set a second config option, and keeps tracing truly opt-in, as the spec says it should be.

Because this has been somewhat in flux, I think our docs are probably inconsistent on this score, and that's definitely something we should fix.