The SDK assumes a trace_sample_rate of 0 means we don't want to trace

[AAllport]

Environment

When running v2.13, setting the SENTRY_TRACES_SAMPLE_RATE to 0.0 will disable the tracing integration.
Whilst this is understandable when serving the frontend via Laravel, this does not work well when using Laravel as an API only.

Our use case has a VueJs frontend, and a Mobile client.
We are enabling performance monitoring and initially hoped to have the sampling decision set on the VueJs frontend for this initial phase.

Due to how couldHavePerformanceTracingEnabled is implemented, a 0 value causes tracing not to be loaded.

sentry-laravel/src/Sentry/Laravel/BaseServiceProvider.php

Lines 47 to 52 in acbf236

	protected function couldHavePerformanceTracingEnabled(): bool
	{
	$config = $this->getUserConfig();
	return !empty($config['traces_sample_rate']) || !empty($config['traces_sampler']);
	}

Steps to Reproduce

1. Enable the SDK with a DSN and 0 Sample rate
2. Have a front end with a positive sampling decision to make a request to the Laravel application.

Expected Result

A backend trace should be sent to Sentry with its parent set to the frontend id

Actual Result

The backend tracing integration was not enabled, and no trace was sent

[stayallive]

For reference this issue was sparked by a conversation in the Sentry Discord: https://discord.com/channels/621778831602221064/621964286952210432/1030461140913897482.

This is assumed to be undefined or at the very least unclear behaviour of the SDK and we should decide how to proceed because it would still be nice to have the SDK not do all the tracing bits if the user is never going to use it, but our very naive heuristic at the moment is obviously also not ideal or correct behaviour.

A workaround for now could be defining your own trace_sampler callback:

'traces_sampler' => function (\Sentry\Tracing\SamplingContext $context): float { return 0.0; },

However this is not ideal of course but does workaround the issue until we figure out how to fix it correctly.

[cleptric]

Just confirmed, we have to respect the sampling decision of the HEAD SDK, so we should instrument this regardless.

[stayallive]

@cleptric how do you want to "fix" this? Want to do a bugfix or make this change in 3.x?

[cleptric]

We should do this right away in a bug-fix release.

[cleptric]

@AAllport First of all, thanks for reporting this. We actually discovered the underlying issue to be in our generic PHP SDK and will need to fix this there first.

[AAllport]

Oh wow, didn't realise there was an issue with both of the SDKs.
I can totally understand how this happened, and it's somewhat of a non-issue for us now we've decided to just enable the sampling decision on all of the backend requests!

My point is, there's no rush from our end!