DefaultProblemDetailsFactory.cs - traceId vs. traceparent

[hannahchan]

Since .NET 5, ASP.NET by default surfaces RFC 7807 - Problem Details responses that look like the following.

{
    "type": "https://tools.ietf.org/html/rfc7231#section-6.6.1",
    "title": "An error occurred while processing your request.",
    "status": 500,
    "traceId": "00-3304f15e4d65e147815f694ffa6162e6-19fbdea7fac6df4c-01"
}

The value in the traceId field is now a W3C Trace Context traceparent header which contains as one of its parts, a trace-id. In the above example, the trace-id is 3304f15e4d65e147815f694ffa6162e6.

To avoid potential confusion, should the field traceId be renamed to traceparent?

Alternatively, is it to better to surface the actual trace-id portion of traceparent as the value of the traceId field? For example;

{
    "type": "https://tools.ietf.org/html/rfc7231#section-6.6.1",
    "title": "An error occurred while processing your request.",
    "status": 500,
    "traceId": "3304f15e4d65e147815f694ffa6162e6" // Displays only the trace-id portion of traceparent
}

I was originally going to raise this as an issue but it's not really breaking anything that I know of at the moment. I'm just being a little pedantic. Either way it would be nice to know what the thought process behind this was.

[pranavkm]

@shirhatti thoughts?

[shirhatti]

I think it's better to use Activity.Id if ActivityIdFormat is W3C. Activity Id is "TraceId-SpanId-Flag"

Preserve current behavior is ActivityIdFormat is Hierarchichal.

EDIT: Sorry, on closer reading, I realized what I described is already the current behavior

[shirhatti]

To answer the OP's question. this was a conscious decision. The though process was to expose the highest fidelity of information in a single identifier to the end user.

Based on whatever distributed tracing system you're using, the traceId may not exist in your backend (due to sampling). With spanId you will at least be able to track other causally related operations associated with this request.