Patch TracerProvider if it already exists

[sentrivana]

If a TracerProvider already exists, patch it. TracerProvider is a singleton, so if we aren't the first ones setting it up, we need to use the existing one.

In tests, reset TracerProvider after each test so that we start with a clean slate and it gets set up anew on init.

[codecov]

Codecov Report

Attention: Patch coverage is 82.35294% with 3 lines in your changes missing coverage. Please review.

Project coverage is 84.78%. Comparing base (f5fb6e7) to head (199485a).
Report is 2 commits behind head on potel-base.

✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
sentry_sdk/opentelemetry/tracing.py	82.35%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@              Coverage Diff               @@
##           potel-base    #4455      +/-   ##
==============================================
- Coverage       84.80%   84.78%   -0.02%     
==============================================
  Files             144      144              
  Lines           14728    14742      +14     
  Branches         2343     2346       +3     
==============================================
+ Hits            12490    12499       +9     
- Misses           1523     1525       +2     
- Partials          715      718       +3     

Files with missing lines	Coverage Δ
sentry_sdk/tracing.py	80.35% <ø> (ø)
sentry_sdk/opentelemetry/tracing.py	90.00% <82.35%> (-10.00%)	⬇️

... and 2 files with indirect coverage changes

[sl0thentr0py]

just a question

there's also the case where someone adds a custom sampler but let's just ignore that for now, worst case we tell people to update their sampler to derive from sentry's sampler if they really want even more custom logic

[sl0thentr0py]

lol til there is for else in python

[sentrivana]

Yeah this is kinda obscure. I used to avoid it for that reason but I somewhat like it now

[sl0thentr0py]

is _TRACER_PROVIDER above different than what get_tracer_provider returns?

[sentrivana]

Yes, there's some extra logic tied around get_tracer_provider, see here

[sl0thentr0py]

but that branch only runs when it's None, anyway doesn't matter that much

[sentrivana]

Ah, got you now. Thought this was about potentially not using _TRACER_PROVIDER at all and switching to get_tracer_provider.

Yeah we can just use _TRACER_PROVIDER on this line, the get_tracer_provider call here is redundant. Will change.

[sentrivana]

there's also the case where someone adds a custom sampler but let's just ignore that for now, worst case we tell people to update their sampler to derive from sentry's sampler if they really want even more custom logic

We can also skip setting the sampler here and tell people to do it themselves. Arguably just overwriting it here silently is not great, but at the same time, we have so much important custom logic in the Sentry sampler that it kinda feels like it should be there from the get go to be able to use the whole thing meaningfully.

[sl0thentr0py]

We can also skip setting the sampler here and tell people to do it themselves.

No, the default experience is more important than custom use cases.

JS exposes a skipOpentelemetrySetup
https://github.com/getsentry/sentry-javascript/blob/61940fc22052e9005043f77c7355db1742d1d78c/packages/node/src/sdk/index.ts#L154