fix: multiple server-tracing headers aren't handled #1077
Conversation
| .addHeader("Server-Timing", "othervalue 1") | ||
| .addHeader("Server-Timing", "traceparent;desc=\"00-9499195c502eb217c448a68bfe0f967c-fe16eca542cd5d86-01\"") | ||
| .addHeader("Server-Timing", "othervalue 2") |
There was a problem hiding this comment.
Do we know the circumstances that would cause this to happen? Seems a little strange, but doesn't violate the http spec, so I suppose the server side can do all kinds of odd things.
I think the test should should be enhanced to cover the case were there are 2+ Server-Timing headers, both of which are parseable but with different values. The logic currently reads like the last one "wins" .... is this intentional? If so, let's assert that intention with test coverage. 👍🏻 Thanks!
There was a problem hiding this comment.
Thank you @breedx-splk for your help.
There was a problem hiding this comment.
CDN in the customer's account is adding its own Server-Timing. They have their own prefix instead of traceparent, so we can distinguish them.
There was a problem hiding this comment.
In most header-emission apis, it is much easier to simply add a single header line than to find an existing one with the same key and then modify or upsert it. So, yes, this is probably going to happen. Likewise, header receipt apis differ in the guarantees they make in terms of how they present this situation (as a unified comma-separated list, as an array of values from a key, etc.). So, I think the client side of this should
- search exhaustively for a
Server-Timingmetric namedtraceparent(across comma-separate values, across multiple header lines), but - make no guarantees about which one will be used if multiple (validly formed)
traceparents are present (just do whatever is easier given the api surface we have at hand).
An alternative would be to add all found valid values as links, but that would require using actual otel span links (which do not require unique names and can have identical attribute keys/values) instead of our current link.* attribute pair. I'd consider that a future goal.
|
Thank you @jtmalinowski! |
|
@jtmalinowski Please do a similar PR against the 1.7.x branch as well. |
|
|
||
| assertThat(attributes).containsOnly(entry(COMPONENT_KEY, "http")); | ||
| private Response.Builder getBaseRuestBuilder(Request fakeRequest) { |
There was a problem hiding this comment.
nit: missed 'q' in request -> getBaseRuestBuilder
When multiple
server-tracingheaders are present, handle all of them. Previously only the first instance would be handled.