feat(tracing): Add interaction transaction as an experiment

[k-fish]

Summary

This adds interactions as an experiment so we can try it out with Sentry SaaS before tuning it for general release. It's behind a rate as an experiment option and only makes idleTransactions on 'click' for now. Future considerations include us likely having differing idleTimeout settings, and being more clever with which data we include, but this should be enough to start experimenting.

For rollout, we can potentially release this as a branch / beta for our SaaS experiment first.

Other:

• re: playwright tests I'll need to fix them since they seem to work in debug but not regularly, I think it's a timeout issue.
• refs earlier convos I've had with @AbhiPrasad about interactions, Auto-instrument user interactions as transactions #5750
• We're planning on introducing the INP web vital via interaction transactions hopefully, if it makes sense. That might change which interaction transactions we choose to send, or we might need dynamic sampling work to bias towards interactions with INP. Otherwise our other main option will be out-of-transaction metrics, which will be a larger amount of work.

[github-actions]

size-limit report 📦

Path	Size
@sentry/browser - ES5 CDN Bundle (gzipped + minified)	19.67 KB (-0.02% 🔽)
@sentry/browser - ES5 CDN Bundle (minified)	60.94 KB (0%)
@sentry/browser - ES6 CDN Bundle (gzipped + minified)	18.46 KB (0%)
@sentry/browser - ES6 CDN Bundle (minified)	54.49 KB (0%)
@sentry/browser - Webpack (gzipped + minified)	20.26 KB (0%)
@sentry/browser - Webpack (minified)	66.24 KB (0%)
@sentry/react - Webpack (gzipped + minified)	20.29 KB (0%)
@sentry/nextjs Client - Webpack (gzipped + minified)	47.28 KB (+0.42% 🔺)
@sentry/browser + @sentry/tracing - ES5 CDN Bundle (gzipped + minified)	26.66 KB (+0.64% 🔺)
@sentry/browser + @sentry/tracing - ES6 CDN Bundle (gzipped + minified)	25.11 KB (+0.79% 🔺)
@sentry/replay ES6 CDN Bundle (gzipped + minified)	41.79 KB (-0.01% 🔽)
@sentry/replay - Webpack (gzipped + minified)	37.91 KB (0%)

[Lms24]

Looking good so far. I wonder if having a dedicated interactionTracesSampleRate is the way to go in the long run (wouldn't this confuse users?). But y'all probably already had conversations about that so take it with a grain of salt.

[Lms24]

Nit but the linter probably complains about this in multiple occurances in this PR:

We don't use optional chaining and nullish coalescing operators in the SDK as their bundle size impact is higher than using "traditional" checks like

Also, for this particular case: It might be the missing morning coffee but I don't entirely understand the 0 > 0 check. Wouldn't this just evaluate to false?

Suggested change

	if (_experiments?.interactionSampleRate ?? 0 > 0) {
	this._registerInteractionListener(_experiments?.interactionSampleRate ?? 0);
	if (_experiments && _experiments.interactionSampleRate != null) {
	this._registerInteractionListener(_experiments.interactionSampleRate || 0);

[mydea]

I think the idea of the code you mentioned is to not register the listener when interactionSampleRate === 0?

[k-fish]

Thanks for looking, both of you 👏

optional chaining and nullish coalescing operators in the SDK as their bundle size impac

Right 😄, I do know that but it's been a bit, I forgot. I'll re-arrange this. Too much product code recently 😏

not register the listener when interactionSampleRate === 0

The default experiments object that gets set into this should be making this 0, if it's either unset or 0, either way we do not want to add a listener as that would affect the side not on the experiment.

I wonder if having a dedicated interactionTracesSampleRate is the way to go in the long run

It's definitely not, you're right. I'd prefer we're smarter about which ones we send, always trying to make sure we have the one represented by INP when I add it, and leverage biasing in dynamic sampling. For now I've added this rate for experimenting since I'm concerned about sending many many times the transactions (interactions are way more frequent on an SPA) for our frontend than we currently do. In general I'd be leaning towards simple / no-config defaults but still offering control in some manner (either here or elsewhere, such as DS) if a user chooses to do so.

I can see users just wanting everything to be sent especially if they are smaller and are easily within their transaction quota. Something to consider before we un-experiment this, at least.

[AbhiPrasad]

added this rate for experimenting since I'm concerned about sending many many times the transactions

For now can we just use tracesSampler to sample based on op name in the frontend and remove logic around a dedicated sample rate? The mobile SDK implementations do not have this. Saves us bundle size also.

I can see users just wanting everything to be sent especially if they are smaller and are easily within their transaction quota

In order to make sure we don't blow up quota we'll have to do the following.

1. Gate this behind some kind of flag (ideally boolean), but default it to false
2. Update the performance monitoring docs Sentry.init instructions to have the flag on by default, so new users get this functionality automatically
3. Flip the flag in the major version

[k-fish]

For now can we just use tracesSampler

I like that, fixed.

[AbhiPrasad]

Also @k-fish mobile team merged in getsentry/develop#766: https://develop.sentry.dev/sdk/performance/ui-event-transactions/