-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
B3 Propagator doesn't handle 64-bit TraceIDs #686
Comments
@MikeGoldsmith @codeboten would you comment? I believe you've studied this. |
Please escalate this to the Spec SIG, as we need to consistently handle this across all of OTel. |
I actually think that the spec provides enough to consistently handle the issue, so I'll not open an issue against the spec repo, but I will add it to the agenda for the next Spec SIG meeting so we can discuss. I think that between the trace API spec declaring that "[t]he OpenTelemetry After surveying the other OTel implementations, I found the following that exhibit the same issue when receiving 64-bit B3
The following implementations left-pad the The following implementations do not validate the The opentelemetry-erlang implementation converts from hex to integer after validating the incoming hex is 16 or 32 digits. The remaining implementations (PHP, Ruby, C++) do not appear to provide B3 propagators. |
Some relevant discussion: w3c/trace-context#349 I agree, we need consistency on whether short Trace-ID should be accepted |
+1 for left padding with zeros |
The B3 spec allows for both 64-bit and 128-bit
TraceID
s, but does not specify how to handle interop between systems that produce/expect different length IDs.The Otel-Go B3 propagator uses
core.TraceIDFromHex()
which requires a hex-encodedTraceID
be 32 hex digits.Should we left-pad incoming
TraceID
values in the B3 propagator prior to decoding, or should we take another approach?The text was updated successfully, but these errors were encountered: