Don't break on 128bit X-B3-TraceId by tossing high bits

[codefromthecrypt]

Problem

The first step of transitioning to 128bit X-B3-TraceId is tolerantly reading 32 character long ids. Until a change is made, those propagating 128bit ids to Medidata.ZipkinTracerModule will have their traces restarted due to a parse failure.

Medidata.ZipkinTracerModule is one of the last libraries that need an update.

Proposal

Change the TraceProvider.parse to leniently parse an unsigned 64bit long from a lower-hex string. This could address 128bit (32 character) ids by throwing away the high bits (any characters left of 16 characters)

Test

When a 128bit id like X-B3-TraceId: 463ac35c9f6413ad48485a3953bb6124 is received, the lower 64 bits (right most 16 characters ex48485a3953bb6124) will become the trace id as opposed to having the trace restarted.

See also

https://github.com/twitter/finagle/pull/553 https://github.com/openzipkin/brave/pull/239

[bvillanueva-mdsol]

Thanks @adriancole for submitting this issue. Proposal looks good! @jcarres-mdsol Is the ruby gem currently doing this or are we planning to support this?

[jcarres-mdsol]

It's Ruby, it's magic, I'm not even sure it needs any changes to make it support it

[codefromthecrypt]

@bvillanueva-mdsol @jcarres-mdsol fyi.. I think this is the only major library left that doesn't process the longer id. I don't have experience in c# code, or would have raised a PR.

[bvillanueva-mdsol]

@adriancole Submitted a PR to address this problem. Thanks for following up. :+1: