Add Information to TraceState Without Creating Span

[tduncan]

Is your feature request related to a problem? Please describe.
I'm in need of a way to modify the trace state to add a custom key/value pair.

From what I can tell adding information to the TraceState requires either 1) hooking into the trace sampling mechanism or 2) creating a new span. Outside of those two use cases there does not appear to be a way to modify the trace state. My use case a custom SpanProcessor within an agent extension so neither of the above use cases applies.

Describe the solution you'd like
A mechanism to append information to the trace state without creating a new Span. Perhaps a addToTraceState method could be added to the ReadWriteSpan interface so the details of modifying the internal TraceState field could be encapsulated and the integrity of the TraceState protected.

Describe alternatives you've considered
There does not appear to be an alternative way to modify the trace state within the Java SDK. Currently the Context is used to propagate information to downstream services, but my understanding is the Context fields are not guaranteed to be retained if the custom extension I'm developing is not configured on a intermediary service.

Additional context
I'm attempting to develop a custom agent extension in which a decision made when considering the root span needs to be available to all participating services downstream in the trace. At the moment the extension is implemented as a custom SpanProcessor where the decision is made and TextMapPropagator where the information encoded/decoded using the Context as necessary. This setup works but does require every participating service to be configured to use the custom extension. It would be ideal if the information could be retained in the event that a service is not using the custom extension.

Other language implementations do allow for explicit modification of the trace state. See golang for a specific example.

[jkwatson]

This sounds like more a use-case for Baggage, rather than trying to modify the TraceState.

It is unlikely that we would allow the Java TraceState to be mutable without a preponderance of evidence that there is a use-case for it from multiple sources. Your is the first ask I have seen for this. I recommend using Baggage for this sort of operation, as it can be propagated whether or not there is a Span at all in the Context, rather than trying to put something into the W3C TraceState.

Note this comment in the Javadoc for TraceState:

 * <p>Implementations of this interface *must* be immutable and have well-defined value-based
 * equals/hashCode implementations. If an implementation does not strictly conform to these
 * requirements, behavior of the OpenTelemetry APIs and default SDK cannot be guaranteed.

Changing this requirement for immutability would potentially be a breaking change, and would necessitate going to version 2 of the APIs, which we would like to avoid at all reasonable cost.

[trask]

Other language implementations do allow for explicit modification of the trace state. See golang for a specific example.

I don't read Go well, but that Go method looks like it returns a new TraceState object as opposed to mutating a TraceState.

the same is possible in Java using:

TraceState.builder()
  .put(key, value)
  .build()

btw, the immutability that @jkwatson mentions above is required by the specification itself:

TraceState is a part of SpanContext, represented by an immutable list of string key/value pairs

(https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#tracestate)

[github-actions]

This has been automatically marked as stale because it has been marked as needing author feedback and has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.

[shahparthiv]

Any update on this issue?

I also need the requirement to add the tracestate key value pair.

[trask]

hi @shahparthiv! since this issue is closed, can you open a new one and include more details about your use case and why #6456 (comment) doesn't work for you? thanks