Cannot upgrade to Sentry 11.0 (w/o tracing) because of OTel dependencies

[whatyouhide]

Description

We cannot upgrade Sentry to 11.0, even though we do not use tracing, because it requires opentelemetry_semantic_conventions 1.x but we're on 0.2.0. This is quite annoying as there's no reason for us to not be able to update given we don't use tracing. This is one of the biggest reasons for warranting a separate package (sentry_tracing). cc @solnic

[linear]

ELIXIR-26 Cannot upgrade to Sentry 11.0 (w/o tracing) because of OTel dependencies

[Odaeus]

Just wanted to chime in and add the specific error for people searching for this. It's also preventing an application I work on from upgrading the package.

== Compilation error in file lib/sentry/opentelemetry/span_processor.ex == ** (CompileError) lib/sentry/opentelemetry/span_processor.ex:7: module OpenTelemetry.SemConv.ClientAttributes is not loaded and could not be found

[solnic]

Hey folks, seems like there's no other way to address this other than to extract OTel stuff into sentry_tracing.

@sl0thentr0py would be good to address this ASAP

[whatyouhide]

If you don't want to extract this you'll need to relax the dependency of OTel libraries pretty dramatically (like, ~> 0.2 or something for most libraries) and then do a lot of compile-time checking of what version of those libs you're on to determine what features you can use.

[whatyouhide]

My 2c: a lot of folks use Sentry for error reporting, but use other tools for tracing (for whatever reason—cost, different infrastructure, whatever).

Making OTel built into the Sentry SDK means that folks now need to worry to actively make sure tracing is disabled in the Sentry SDK if they use other tools. I know it's kind of opt in, but I can tell from experience that it can cause platform engineers (like me) stress to double and triple check nothing is going to be reported.

A separate package would likely solve this.

[jeregrine]

Upgrading to {:opentelemetry_phoenix, "~> 2.0.1"} seems to fix it?