Open springheeledjak opened 7 years ago
@springheeledjak It may be that the best way to accomplish this is with arg2 request headers and to simply leave the TChannel trace as null. It’s very unlikely that my group or my company's opentracing group is going to invest in a protocol revision for this feature.
However, if there is broad community interest in building and supporting a protocol rev, let the relevant parties chime in here.
@kriskowal Hm, didn't think of that; using arg2
headers sounds like a reasonable approach. I suppose a pair of init
req/res headers could be used to signal intent to use arg2
headers and acceptance, which would serve as the negotiation/downgrading mechanism.
Oh, by way of background, since we framed TChannel protocol some time ago, we have learned a few things that are relevant:
OpenZipkin has added support for 128-bit trace IDs, which have a number of advantages over 64-bit ones (also enumerated in the linked issue). It would be useful to support 128-bit trace IDs in TChannel, as it would enable more seamless integration with, among others, AWS'
X-Amzn-Trace-Id
header and GCE'sX-Cloud-Trace-Context
/ Stackdriver Trace. Span IDs remain 64-bit in both Zipkin and Stackdriver, so that field should stay the same. (128-bit span IDs don't make much sense anyway.)Due to the fixed nature of TChannel headers, this may end up being something of a pain, possibly involving a new protocol version to allow for negotiation during the
init
phase.