Jaeger clients should generate full-length trace/span IDs

[yurishkuro]

Requirement - what kind of business use case are you trying to solve?

As a user, I should be able to use Trace/span IDs encoded in the trace context (e.g. uber-trace-id header) or exposed via SpanContext.toTraceID() methods to refer to traces in the UI.

Problem - what in Jaeger blocks you from solving the requirement?

Currently, many Jaeger clients drop leading zeroes from hex representation of trace/span IDs, resulting in inconsistent strings returned in JSON to the UI (relates to #1578). This is done as an optimization of the trace context header length, but it's a silly one since it only affects about 1/16th of all traces.

Proposal - what do you suggest to solve the problem or improve the existing situation?

Client libraries should always output hex strings of 16 or 32 characters in length, depending on on whether 64bit or 128bit IDs are used, padded with zeros on the left to the desired length.

For backwards compatibility, clients should still be able to parse shorted hex strings.

• Node.js client Do not strip leading zeros jaeger-client-node#391
• Go client Do not strip leading zeros from trace IDs jaeger-client-go#472
• Java client Do not strip leading zeros from trace IDs jaeger-client-java#746 (released in 1.5.0)
• Python client
• C# client Do not strip leading zeros from Trace and Span IDs jaeger-client-csharp#171 (released in 0.4.0)
• C++ client Do not strip leading zeros from trace IDs and span IDs jaeger-client-cpp#259 (pending 0.7.0 release)

[SezalAgrawal]

Is this issue resolved?

[yurishkuro]

It is not, see the checklist in the description.

[yurishkuro]

Per #3362, we're sunsetting Jaeger clients.