TraceID and SpanID as [u8];

[jasl8r]

I am just getting started with fastrace and I've been reading some of the opentelemetry specs as I do.
In fastrace TraceID is a u128 and SpanID is a u64, however opentelemetry specifies that is should be a
[u8; 16] and [u8; 8] respectively. This is of course not important when the data stays on the same system
but when the traces are sent to other systems (with the ids sent via HTTP headers for example) there
needs to be a wire endianness enforced (presumably Big) and this endianness needs to be accounted for
when serializing and deserializing the IDs. The fastrace library does not appear to account for endianness
when serializing and deserializing, just using format! and from_str_radix causing invalid IDs to possibly be used.

[andylokandy]

I checked this path end-to-end, and if we set aside the current decode strictness issue, this is not an endianness bug. traceparent IDs are fixed hex strings, fastrace parses them as values, and re-encodes them with fixed-width hex, so the canonical ID stays stable.

That means both W3C -> fastrace -> OTel and OTel -> fastrace -> W3C point to the same trace on both little-endian and big-endian platforms. So for this specific concern, fastrace does not need to change its internal ID representation.

[jasl8r]

That makes sense and is what I figured. The concern here is that you need to use fastrace as the inbound deserialize and the outbound serializer, so a user should never access the traceID or spanID directly and allow it to exit the instance bypassing the serializer, i.e. if for some reason you were passing traces across a different/custom channel and were running your own serializer on the struct. I think it would be a good idea to clearly state this in the documentation or at least the code.