Skip to content

Conversation

@jamescrosswell
Copy link
Collaborator

@github-actions
Copy link
Contributor

github-actions bot commented Feb 9, 2026

Semver Impact of This PR

None (no version bump detected)

📋 Changelog Preview

This is how your changes will appear in the changelog.
Entries from this PR are highlighted with a left border (blockquote style).


Features ✨

  • feat: Add support to send OTEL traces via OTLP by jamescrosswell in #4899

Dependencies ⬆️

Deps

  • chore(deps): update Java SDK to v8.32.0 by github-actions in #4843
  • chore(deps): add protobuf-javalite 3.25.8 dependency on Android by github-actions in #4843
  • chore(deps): Bumped Xamarin.AndroidX.Lifecycle.Common.Java8 and CommunityToolkit.Mvvm to 2.2.20 and 8.4.0 by jamescrosswell in #4876

Other

  • ci: Skip device tests for non-mobile PRs by bruno-garcia in #4909

🤖 This preview updates automatically when you update the PR.

@github-actions
Copy link
Contributor

github-actions bot commented Feb 9, 2026

Fails
🚫 Please consider adding a changelog entry for the next release.
Messages
📖 Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Instructions and example for changelog

Please add an entry to CHANGELOG.md to the "Unreleased" section. Make sure the entry includes this PR's number.

Example:

## Unreleased

### Features

- Add support to send OTEL traces via OTLP ([#4899](https://github.com/getsentry/sentry-dotnet/pull/4899))

If none of the above apply, you can opt out of this check by adding #skip-changelog to the PR description or adding a skip-changelog label.

Generated by 🚫 dangerJS against 6f8312d

// Finally we configure OpenTelemetry to send traces to Sentry
.AddSentry()
// Finally, we configure OpenTelemetry to send traces to Sentry
.AddSentry(dsn)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is unfortunately a bit more complex for SDK users to initialise because the TracerProviderBuilder.AddOtlpExporter method has no override with an IServiceProvider parameter (so there's no way to read the DSN from the sentry options that get added to the service registry later on).

<PackageReference Include="OpenTelemetry.Instrumentation.AspNetCore" Version="1.8.1" />
<PackageReference Include="OpenTelemetry.Instrumentation.Http" Version="1.8.1" />
<PackageReference Include="OpenTelemetry.Instrumentation.Runtime" Version="1.8.0" />
<PackageReference Include="OpenTelemetry.Exporter.OpenTelemetryProtocol" Version="1.8.1" />
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without adding an explicit reference to this package, we get an error because the other packages try to load types from a different assembly version. It's the workaround for this problem basically.

/// </para>
/// </param>
/// <returns>The supplied <see cref="TracerProviderBuilder"/> for chaining.</returns>
public TracerProviderBuilder AddSentry(TextMapPropagator? defaultTextMapPropagator = null)
Copy link
Collaborator Author

@jamescrosswell jamescrosswell Feb 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could mark this overload obsolete if we wanted to encourage SDK users to move to the OTLP version of the integration... then remove it in a future major release.

@codecov
Copy link

codecov bot commented Feb 9, 2026

Codecov Report

❌ Patch coverage is 25.71429% with 52 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.69%. Comparing base (48b744f) to head (907850b).
⚠️ Report is 10 commits behind head on main.

Files with missing lines Patch % Lines
...y.OpenTelemetry/TracerProviderBuilderExtensions.cs 5.26% 18 Missing ⚠️
...rc/Sentry.OpenTelemetry/SentryOptionsExtensions.cs 0.00% 13 Missing ⚠️
src/Sentry.OpenTelemetry/OtelPropagationContext.cs 0.00% 8 Missing ⚠️
...i.CommunityToolkit.Mvvm/SentryOptionsExtensions.cs 0.00% 3 Missing ⚠️
src/Sentry/Internal/Hub.cs 0.00% 2 Missing and 1 partial ⚠️
src/Sentry/SentryGraphQLHttpMessageHandler.cs 0.00% 2 Missing and 1 partial ⚠️
src/Sentry/SentryHttpMessageHandler.cs 0.00% 2 Missing and 1 partial ⚠️
src/Sentry/Dsn.cs 0.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4899      +/-   ##
==========================================
- Coverage   73.87%   73.69%   -0.18%     
==========================================
  Files         494      495       +1     
  Lines       17868    17919      +51     
  Branches     3509     3523      +14     
==========================================
+ Hits        13200    13206       +6     
- Misses       3808     3851      +43     
- Partials      860      862       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@jamescrosswell
Copy link
Collaborator Author

Please add an entry to CHANGELOG.md to the "Unreleased" section. Make sure the entry includes this PR's number.

Odd that we're still seeing this after having moved to conventional commits.

It doesn't look like the danger workflow is aware of our release.yml file or accounts for this in it's logic.

@Flash0ver any ideas what we might be doing wrong?

@Flash0ver
Copy link
Member

@Flash0ver any ideas what we might be doing wrong?

I'm not sure how to remove the Danger Changelog Missing automation off the top of my head ... I'll look into it tomorrow.

return NoOpTransaction.Instance;
}

if (_options.Instrumenter == Instrumenter.OpenTelemetry)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be a pretty major change...

  • It would break the Sentry.Extensions.AI integration for a start (we'd need to provide a Sentry.Extensions.AI.OpenTelemetry integration instead).
  • It may break lots of user code that assumes we support mixed instrumentation in a single process (which we did up until now)

Potentially we leave this commented out as a todo for v7.0.0 and we just strongly advise SDK users not to use mixed instrumentation until then as we can't guarantee it will work as expected.

@Flash0ver @dingsdax thoughts?

<ItemGroup>
<!-- Version 1.6.0 is the minimum version that does not have trim warnings -->
<PackageReference Include="OpenTelemetry" Version="1.6.0" />
<PackageReference Include="OpenTelemetry.Exporter.OpenTelemetryProtocol" Version="1.6.0" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

next major: consider bumping to >= 1.11.0, as the dependency graph looks cleaner

/// </summary>
/// <exception cref="ArgumentOutOfRangeException">Can be thrown when using OpenTelemetry instrumentation and
/// System.Diagnostics.Activity.Current is null. This method should not be used when instrumenting with OTEL.
/// </exception>
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is problematic... the alternative would be to drop the guard here:

// Validate and set required values
if (traceId == SentryId.Empty)
{
throw new ArgumentOutOfRangeException(nameof(traceId), "cannot be empty");
}

...or to replace it with a log rather than throwing an exception. However then I think we risk sending invalid envelopes to Sentry and losing events if Sentry drops these.

I think this is the correct approach. The only code that we have which was using this was in the SentryMessageHandler implementations.

There is one small additional risk because it's also used by the GetBaggage method, which is part of the public SDK. I added some code to log a warning if that method is called when OTEL instrumentation is being used:

public BaggageHeader GetBaggage()
{
if (_options.Instrumenter is Instrumenter.OpenTelemetry)
{
_options.LogWarning("GetBaggage should not be called when using OpenTelemetry - it may throw an exception");
}
var span = GetSpan();
if (span?.GetTransaction().GetDynamicSamplingContext() is { IsEmpty: false } dsc)
{
return dsc.ToBaggageHeader();
}
var propagationContext = CurrentScope.PropagationContext;
return propagationContext.GetOrCreateDynamicSamplingContext(_options, _replaySession).ToBaggageHeader();
}

And I added some info about the possible exception to the public XML docs for that method:

/// <exception cref="ArgumentOutOfRangeException">Can be thrown when using OpenTelemetry instrumentation and
/// System.Diagnostics.Activity.Current is null. This method should not be used when instrumenting with OTEL.
/// </exception>

It's not great, but I can't think of any better ways to handle it. @Flash0ver thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Investigate OTLP integration

2 participants