`http.server` spans are incorrectly generated for non-2xx status codes when using OTel integration

[tvardero]

Package

Sentry.OpenTelemetry

.NET Flavor

.NET Core

.NET Version

10.0.104

OS

Linux

OS Version

Fedora 43 Workstation

Development Environment

Rider 2025.x (Linux)

Other Error Monitoring Solution

No

Other Error Monitoring Solution Name

No response

SDK Version

6.2.0

Self-Hosted Sentry Version

25.11.0

Workload Versions

not applicable

UseSentry or SentrySdk.Init call

using OpenTelemetry.Trace;
using Sentry.OpenTelemetry;

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();

builder.WebHost.UseSentry(c =>
{
    c.DisableSentryHttpMessageHandler = true;
    c.UseOpenTelemetry();
});

builder.Services.AddOpenTelemetry()
    .WithTracing(t =>
    {
        t.AddAspNetCoreInstrumentation();
        t.AddSentry();
    });

WebApplication app = builder.Build();

app.MapControllers();

app.Run();

Steps to Reproduce

1. Create 2 endpoinds:
   • one returns 200, call it POST /GoodEndpoint
   • second throws an exception, call it POST /BadEndpoint
2. Call them and examine traces in Sentry.

Expected Result

Endpoints that throws an exception should generate http.server transaction with POST /BadEndpoint name.
Failure rate for POST /BadEndpoint is 100%.

Actual Result

Endpoints that throws an exception generate http.server transaction with Microsoft.AspNetCore.Hosting.HttpRequestIn name.
Failure rate is POST /BadEndpoint is 0%, as all failures are recorded under Microsoft.AspNetCore.Hosting.HttpRequestIn.

This really prevents from analyzing what endpoint throws and what doesnt when looking at list of 100 endpoints. All of them have 0% failure rate, as all failures are collected under single Microsoft.AspNetCore.Hosting.HttpRequestIn.

[linear-code]

NET-634

[tvardero]

good_trace.json
bad_trace.json

I have noticed that contexts does not have otel in bad trace. As well as transation_info.source is custom instead of route. Source is set in Sentry.OpenTelemetry.SentrySpanProcessor.ParseOtelSpanDescription.

[jamescrosswell]

@tvardero could I get you to put together a trivial minimal repro? That would make it easier to look into (we're pretty stretched at the moment).

[github-actions]

👋 Thanks for the report! We've added the Needs Reproduction label because we need a minimal reproduction to investigate further.

Please provide a link to a public GitHub repository that reproduces the issue with as little code as possible. Our repro guide has tips on how to create one.

Some quick hints:

• Start from a fresh dotnet new console (or similar) project
• Add only the Sentry NuGet package(s) relevant to the bug
• Include the exact SDK version number and your SentrySdk.Init / UseSentry call (with the DSN blanked out)

Alternatively, if the issue only manifests in your own codebase, you could try gradually removing code until you have a minimal repro.