Is there a built-in mechanism for returning traceresponse header?

[danielloganking]

I'm looking for something similar to this propagator in the python client. Basically, I would like to return tracing information as a response header for any traced ASP.NET request. Obviously if such a thing does not exist I can code it myself but I figured I'd ask here first so I don't end up duplicating work.

If it doesn't yet exist, would such a feature be welcome/valuable to add either here or in one of the specific instrumentors in opentelemetry-dotnet-contrib?

[cijothomas]

I'd suggest opening an issue in the specification repo as this is not language specific.

[danielloganking]

I'm not quite sure I understand your reply. Do you mean to say that because traceresponse is not part of the final W3C trace context spec and is still in the experimental/internal/non-standard implementations stage that it is not eligible for inclusion in the code published here (which makes sense as this is the base .NET SDK) or in opentelemetry-dotnet-contrib (which seems appropriate for useful but non-standard helpers)? And that if I wanted such code included in either repo I should instead focus my efforts on encouraging the adoption of traceresponse within its own standard?

Thank you for your help!

PS: I still plan on implementing this but am trying to figure out if I should upstream the work or not 👍

[cijothomas]

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/context/api-propagators.md#propagators-distribution I meant the OpenTelemetry spec, since this feature is not language specific, and we generally implement things based on the Otel specification.
Nothing wrong in including in -contrib repo, but definitely not in the main repo (this), as you already mentioned.

[cijothomas]

open-telemetry/opentelemetry-specification#1355 spec issue is alredy there?

[danielloganking]

Yes. The traceresponse headers are coming to the standard eventually (caveat being the header key isn't decided) but aren't there yet. I do think this is likely a useful bit of functionality and it seems unlikely it will change too terribly much during the standardization. I'll see what I can do and try to get a PR up to -contrib 👍

[davidwallis]

did you manage to do anything with this? I'm looking at how to return it just for some debugging / poc initially.

[danielloganking]

I never got around to putting up a PR to -contrib (work got in the way); but I have added this to my APIs with the following middleware as part of my application startup:

// add otel traceresponse headers to all requests if active
app.Use((context, next) =>
{
    // format: {version}-{trace_id}-{span_id}-{flags}
    // flags currently only means "sampled" (01) or "not sampled" (00)
    // version currently defined to be 00
    context.Response.Headers["traceresponse"] = Activity.Current?.Id;
    return next.Invoke();
});

[MistyKuu]

@danielloganking Out of interest, shouldn't that be HttpContext.TraceIdentifier instead?
There was debate about which one to use: https://stackoverflow.com/questions/70828928/difference-between-httpcontext-traceidentifier-and-activity-current-id
In ProblemDetailsFactory in .NET, it uses Activity.Current.Id ?? HttpContext.TraceIdentifier
As far as I understand, Acitvity.Current.Id would return trace header that contains current span id while TraceIdentifier would return span (activity) id of top most span when request started.

[davidwallis]

That's perfect for what I need, appreciated.