IHttpActivityFeature.Activity and Activity.Current don't return the same activity

[ghost]

Description

Considering the following example:

using System.Diagnostics;
using Microsoft.AspNetCore.Http.Features;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddOpenTelemetry()
    .WithTracing(builder =>
    {
        builder
            .SetSampler(new AlwaysOnSampler()) // note here I use the AlwaysOn sampler to always record and sample activities
            .AddAspNetCoreInstrumentation()
            .AddConsoleExporter();
    });

var app = builder.Build();

app.MapGet("/values", (HttpContext context) =>
{
    var activity = context.Features.GetRequiredFeature<IHttpActivityFeature>().Activity;
    activity.SetTag("test", "123");

    Activity.Current?.SetTag("test2", "123");

    return Results.Ok();
});

app.Run();

When the application receives a traceparent header with a trace-flags 00 (not sampled),activity.Id and Activity.Current.Id don't have the same id but both activities have the same name: Microsoft.AspNetCore.Hosting.HttpRequestIn.
In addition, only tags added through Activity.Current.SetTag are taken into account.

This seems to be a bug or an unexpected behaviour with the OpenTelemetry SDK as without the SDK both activities are the same and both tags are taken into account.

What is the expected behavior?

Both activities (the one from IHttpActivityFeature.Activity and the one from Activity.Current) should be the same.

What is the actual behavior?

Both activities are not the same.

[cijothomas]

Looks like an bug in the way Instrumentation.AspNetCore works. It has some logic to "ignore" the Activity created by Asp.Net Core itself, and create a new one. This is only meant to be triggered when non W3CTraceContext propagator is used, but it looks like it is triggered (incorrectly), in the case a traceparent with "00" traceflags is being sent.

Looks like https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/src/OpenTelemetry.Instrumentation.AspNetCore/Implementation/HttpInListener.cs#L138 should ignore traceflags from the comparison, as TraceFlags is expected to be changed, unlike traceid,spanid.

[cijothomas]

@vishweshbankwar Could you take a look?

[vishweshbankwar]

@joegoldman2 We do not have an ETA on this. In the meantime, you could use Activity.Current as a workaround.

[ngruson]

OP account is deleted, but I can't reproduce this behavior in the given example with the current codebase.
Did anyone reproduce this at the time?
activity.Id is equal to Activity.Current.Id when I run the example.
The id starts with '00-'.

app.MapGet("/values", (HttpContext context) =>
{
    var activity = context.Features.GetRequiredFeature<IHttpActivityFeature>().Activity;
    activity.SetTag("test", "123");

    Activity.Current?.SetTag("test2", "123");

    var equal = Activity.Current.Id == activity.Id;
    // equal is true

    return Results.Ok();
});

[vishweshbankwar]

OP account is deleted, but I can't reproduce this behavior in the given example with the current codebase. Did anyone reproduce this at the time? activity.Id is equal to Activity.Current.Id when I run the example.

app.MapGet("/values", (HttpContext context) =>
{
    var activity = context.Features.GetRequiredFeature<IHttpActivityFeature>().Activity;
    activity.SetTag("test", "123");

    Activity.Current?.SetTag("test2", "123");

    var equal = Activity.Current.Id == activity.Id;
    // equal is true

    return Results.Ok();
});

@ngruson Did you send the traceparent header in the request with flags set as 00?

[ngruson]

Ah, the header. Will recheck tomorrow.