Codecov Report

Base: 98.33% // Head: 98.33% // Increases project coverage by +0.00% 🎉

Coverage data is based on head (248ad25) compared to base (5bfdf80).
Patch coverage: 100.00% of modified lines in pull request are covered.

@@           Coverage Diff           @@
##           master    #1944   +/-   ##
=======================================
  Coverage   98.33%   98.33%           
=======================================
  Files         151      151           
  Lines        9306     9369   +63     
=======================================
+ Hits         9151     9213   +62     
- Misses        155      156    +1     

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

Should this be applied to sentry-sidekiq, sentry-resque, and sentry-delayed_job as well?
If the answer is yes, can we encapsulate Sentry.configuration.instrumenter == :sentry with something like Sentry.configuration.native_instrumenter? or Sentry.configuration.default_instrumenter??

@st0012 so the idea was to make this config as non-interfering as possible, since we don't know the future of this feature.

I don't want to add top-level apis we commit to for now, so the idea was to no-op the top-level hub start_transaction/with_child_span apis and also not to change every callsite. All the other gems/integrations should remain backwards compat with minimal change.

I added the rails check because of the span nil issue, which is fine in this case I think to avoid all the checks.

Potential users of sentry-opentelemetry will also ideally not add sentry-rails|sidekiq|delayed_job|resque since they will be using the otel sdk for instrumentation, so this is also another argument be made for leaving the other integrations untouched.

Potential users of sentry-opentelemetry will also ideally not add sentry-rails|sidekiq|delayed_job|resque since they will be using the otel sdk for instrumentation, so this is also another argument be made for leaving the other integrations untouched.

Do we do error monitoring/add breadcrumbs via sentry-rails|sidekiq|delayed_job|resque? If yes, this will mean that they have to use these integrations anyway.

hmm yea, nvm you're right, ignore that second argument
the other argument about not changing the call-sites still holds.

@sl0thentr0py Can you also add tests to those integrations to make sure they don't raise errors when the instrumenter is otel?

added config/otel specs to other gems