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

Match Trace IDs output to logs to those in Jaeger

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

Jaeger interprets Trace IDs in a mysterious way that makes the hexed ID completely different

I have an application that uses OpenCensus to generate spans and traces and then sends those to Jaeger using the Thrift interface. At the same time it logs the current Trace ID with the log entries so that we can match the traces from Jaeger to application logs. Except these IDs don't seem to match. Sometimes they do however.

A couple examples (The application is written in Elixir and I used that to parse so I'll use the byte syntax to show binaries)

Trace ID generated by the application:
0e7b69838055876fdf8b7ee0ecfc276a

Trace ID in Jaeger:
e7b69838055876fa074811f1303d895

If we look at it in binary format:
Application:
00001110011110110110100110000011100000000101010110000111011011111101111110001011011111101110000011101100111111000010011101101010
Jaeger:
11100111101101101001100000111000000001010101100001110110111110100000011101001000000100011111000100110000001111011000100100000101

If you look closely it seems that leading zeros have been removed (I found #1578 but it seems only somewhat related to this problem) while the lower part is inverted? Upper part has leading zeroes while lower part has a leading 1.
Application upper:
0000111001111011011010011000001110000000010101011000011101101111
Jaeger upper:
1110011110110110100110000011100000000101010110000111011011111010

Application lower:
1101111110001011011111101110000011101100111111000010011101101010
Jaeger lower:
0000011101001000000100011111000100110000001111011000100100000101

Trace ID generated by the application:
3b4b7e0eb55df3283a352c86fa0df6af

Trace ID in Jaeger:
3b4b7e0eb55df3283a352c86fa0df6af

Binary:
00111011010010110111111000001110101101010101110111110011001010000011101000110101001011001000011011111010000011011111011010101111

This one seems to match perfectly? I noticed that both lower and upper half have leading zeroes.

Upper:
0011101101001011011111100000111010110101010111011111001100101000
Lower:
0011101000110101001011001000011011111010000011011111011010101111

Trace ID generated by the application:
9fd1aaa32ff34ca5ad7869260f54dc08

Trace ID in Jaeger:
e02e555cd00cb35ad28796d9f0ab23f7

Binary:
Application:
10011111110100011010101010100011001011111111001101001100101001011010110101111000011010010010011000001111010101001101110000001000
Jaeger:
11100000001011100101010101011100110100000000110010110011010110101101001010000111100101101101100111110000101010110010001111110111

Now both lower and upper have leading 1s causing weird things to happen most notable bits invert:

Application upper:
1001111111010001101010101010001100101111111100110100110010100101
Jaeger upper:
1110000000101110010101010101110011010000000011001011001101011010

Application lower:
1010110101111000011010010010011000001111010101001101110000001000
Jaeger lower:
1101001010000111100101101101100111110000101010110010001111110111

Is this some unsigned/signed magic that is happening that causes Jaeger to interpret these numbers differently? Is this some 1s complement magic with a sign bit? I am very confused and don't know if it is something I can change in my application (or rather the reporter library) or is it something in Jaeger? I am running jaeger with jaegertracing/all-in-one:1.14 Docker image, but have seen the same problem happen on the latest image.