[response header] Representing server span ID vs proposed parent ID

[dyladan]

How should the response header distinguish between the server span ID and the span ID the server is proposing for the client?

[dyladan]

As raised by @adriancole in #365, is proposed-span-id a use case we want to support? I included it in the initial PR because of the discussions we had at the last face to face, but is the use case better solved some other way?

Adrian correctly observed that some tracing systems have solved this problem in other ways, however browser correlation is tricky and error-prone business in its current state. As an optional field, systems which don't want to support proposed parents don't have to; receiving request with no traceparent does not obligate you to propose one in the response, and receiving a proposed parent doesn't obligate you to use it.

[yurishkuro]

I think it would be useful to document what the alternative solution would be for browser correlation.

[codefromthecrypt]

Historical discussions were about the trace ID, that being the most important thing to send backwards. openzipkin/b3-propagation#4

There is existing practice about returning your own ID back in response headers. B3 has been abused for this, and also X-Ray propagation does this in some cases, iirc.

I think response header definition could be decoupled entirely from if any ID (except trace ID) is sent back. Even if trace ID is sent back there's trouble if you have multiple concurrent calls, as they would have different back propagated trace IDs for what could be the same overall trace. For this reason I would recommend at least to OSS people to push forward your trace context, following normal semantics defined in the format, vs expect to be able to neatly tie up things afterwards. To be able to neatly tie up things in practice would require more text than the current spec has imho.

[dyladan]

Even if trace ID is sent back there's trouble if you have multiple concurrent calls, as they would have different back propagated trace IDs for what could be the same overall trace.

Multiple returned trace ids is not a problem. The trace id in the response header is not a trace id that the caller should use, but is merely for support concerns. ex if I call a GCP service, they can return their internal trace id to me so that I may give it to a support representative during debugging. Most likely I would just add that response header's trace id as a span attribute on the outgoing span.

[codefromthecrypt]

Even if trace ID is sent back there's trouble if you have multiple concurrent calls, as they would have different back propagated trace IDs for what could be the same overall trace. Multiple returned trace ids is not a problem. The trace id in the response header is not a trace id that the caller should use, but is merely for support concerns. ex if I call a GCP service, they can return their internal trace id to me so that I may give it to a support representative during debugging. Most likely I would just add that response header's trace id as a span attribute on the outgoing span.

"The trace id in the response header is not a trace id that the caller should use" is great. If response headers are sent back, this should be in the spec description!

[dyladan]

No longer relevant after #406. #407 created to address @adriancole's most recent feedback.