Document handling of tracestate duplicate keys about trace-context HOT 6 CLOSED

Hey Robert,

the intention of the wording in the spec is that there is a difference between receiving a tracestate header and modifying it for sending it downstream.

That is, if you add a key to tracestate, you MUST make sure that this key only exists once in the list, no matter if it occurred 0 time, once or multiple times before you modified tracestate. This is what https://w3c.github.io/trace-context/#mutating-the-tracestate-field is about, in particular the sentence "Adding a key/value pair MUST NOT result in the same key being present multiple times."

However, if you receive the tracestate header, you are not responsible for validating the uniqueness of tracestate list members, nor are you responsible for removing duplicated headers. But: If you want to, you can. (exact wording: "Finally, vendors MAY also discard duplicate keys that were not generated by them.") Reasoning: Some implementations might not want to spend the computational overhead of even reading/parsing the full tracestate header, and the spec should not force them to do that. OTOH, there are limits for the length of the tracestate keys, and sometimes, implementations may need to drop key value pairs. Allowing to drop key value pairs that are obviously invalid anyway (because of duplicated keys) seems reasonable.

I am not sure if this background is helpful? In my opinion, the two pieces of test code you linked to agree with that interpretation. Do you see an issue with these tests? Or was your comment around the aspect that the spec should mandate one specific behavior instead of allowing two behaviors?

By the way, you referenced a fork of the spec (coincidentlly, my fork :-) ) at https://github.com/instana/trace-context/blob/master/spec/20-http_request_header_format.md. Forks might be outdated/unmaintained. We recommend to always reference this repository. Use the main branch for the latest version (which might contain unpublished edits that will never make it into a published spec) or the level-2 etc. branches for the respective level of the spec.

from trace-context.

Thanks Bastian - assigning to you per our discussion in the Working Group meeting.

from trace-context.

First of all, thanks a lot for your response. I really apricate the amount of effort you put into explaining.

The reason I am asking is that I try to double-check if the current behavior (returns an error when there is a duplicate key) of https://pkg.go.dev/go.opentelemetry.io/otel/trace#ParseTraceState is correct. Reference: open-telemetry/opentelemetry-go#4638

However, if you receive the tracestate header, you are not responsible for validating the uniqueness of tracestate list members, nor are you responsible for removing duplicated headers.

How does it play with the following from https://w3c.github.io/trace-context/#combined-header-value:

Only one entry per key is allowed.

This fragment feels like duplicates are not really allowed.

from trace-context.

I think this is still in line with what I said earlier about the different responsibilities and perspectives when receiving the header and modifying it yourself. The intent of that paragraph is to explain that participants modifying tracestate are not supposed to add "their own" key multiple times. But I agree that the phrasing is a bit misleading.

How about we change

Only one entry per key is allowed. For example, if a vendor name is Congo and a trace started in their system and then went through a system named Rojo and later returned to Congo, the tracestate value would not be:

to

Tracing tools are not supposed to add the same header multiple times. For example, if a vendor name is Congo and a trace started in their system and then went through a system named Rojo and later returned to Congo, the tracestate value would not be:

Do you think that would clarify this point?

from trace-context.

Do you think that would clarify this point?

Yes 👍

from trace-context.

How about we change

Only one entry per key is allowed. For example, if a vendor name is Congo and a trace started in their system and then went through a system named Rojo and later returned to Congo, the tracestate value would not be:

to

Tracing tools are not supposed to add the same header multiple times. For example, if a vendor name is Congo and a trace started in their system and then went through a system named Rojo and later returned to Congo, the tracestate value would not be:

See #552.

from trace-context.