Open Lms24 opened 1 month ago
For reference: https://github.com/getsentry/sentry-javascript/issues/9095
The function hasTracingEnabled
checked if certain options are truthy. tracesSampleRate
and tracesSampler
still make sense as they allow modifying the enabled tracing configuration. But what should be the behavior for enableTracing: false
?
The function
hasTracingEnabled
checked if certain options are truthy.tracesSampleRate
andtracesSampler
still make sense as they allow modifying the enabled tracing configuration. But what should be the behavior forenableTracing: false
?
IMHO this check can remain as it is? as soon as this is defined that is enough, for all of these fields!
Just to confirm: Are we talking about the correctness of hasTracingEnabled
itself or about how it us used to guard adding the browserTracingIntegration
s?
No, not about the correctness of hasTracingEnabled
, but what options it considered before and which action to take now based on the options, but without the function. For example, what should be the outcome if enableTracing
is false
?
I'd say we can safely ignore enableTracing
here because there should be a check within browserTracingIntegration
if a span should be started and even if not, a negative sampling decision would be returned based on enableTracing
(but preferrably other options, given that enableTracing
is deprecated).
If users would still like to avoid TwP scenarios there's still another escape hatch: tracePropagationTargets: []
means tracing headers aren't attached to any outgoing requests.
Problem Statement
Currently, our meta-framework SDKs (in contrast to the frontend framework and base browser SDKs) automatically add
browserTracingIntegration
if:__SENTRY_TRACING__
tree-shaking flag is not replaced at build timehasTracingEnabled
returns true, meaningtracesSampleRate
,tracesSampler
orenableTracing
options are setThe second (2) condition unfortunately breaks "Tracing without Performance" which in our frontend framework SDKs is enabled as soon as
browserTracingIntegration
is added but no sample rates are set. Adding to this, there is no bundle size advantage in not addingbrowserTracingIntegration
because thehasTracingEnabled
check is performed at runtime. This results in the integration code always being added to the bundle.We realized this while working on and reviewing #13005
Solution Brainstorm
We're going to change the behaviour here to remove condition 2 entirely. Meaning, by default,
browserTracingIntegration
will always be added, unless users configure the tree shaking flag (1). This change should be implemented in all our meta framework SDKs that currently automatically addbrowserTracingIntegration
.The benefits of always adding the integration are:
transaction
field is populated via the framework'sbrowserTracingIntegration
settingscope.transactionName
. This means higher quality transaction names out of the box.Bundle size isn't wasted like before
Implementation
Implementing this behaviour requires two changes:
hasTracingEnabled
guard in the SDK initializationsentrySvelteKit
vite plugin or Astro integration options) for users to easily opt out of tracing. This option should pass the boolean to the Sentry bundler plugin'sbundleSizeOptimizations.excludePerformanceMonitoring
option.