-
Notifications
You must be signed in to change notification settings - Fork 11
PHP 64 bit signed int causing issues with Trace ID #7
Comments
This would need to be fixed upstream in the Thrift PHP package as it expects integer values to |
Agreed, but how is anyone using the jaeger exporter at all (or Thrift PHP for that matter)? Are people just finding a way to limit Int64 generation in PHP to below the cutoff? |
The core opencensus-php library only generates trace and span ids with 32 bits of randomness. For a standalone PHP application, it should be good enough. If it's in a SOA where the trace id is propagated and the trace id generated is 64-bit, then this will not work unless we can fix Thrift upstream (or switch Thrift implementations if there is one). |
So from my example above the 64 bit int should be 13416282260834112909, which PHP cannot handle. We can use BC Math to get the true value as a string. function bchexdec($hex) { That would return the correct value for my example id. But it doesn't look like the Thrift library can support a string representing an I64. I guess I could modify my upstream id generators to only use 32 bit ids, but as many are starting to use 128 bit IDs, would be good to get a fix. |
@chingor13 I think this should be fixed by my PR |
Fixed in #8 |
The SpanConverter class uses hexdec to convert the traceId (both high and low is using 128bit ids) to an integer for the Thrift package, the issue is that PHP doesn't support unsigned ints, so any ID above 0x7FFFFFFFFFFFFFFF will be output as a float and will lose precision.
When converted back it will have changed the spanId
will output
I have had to fall back to the zipkin exporter, even though I am pushing to Jaeger, as it uses strings for the ID and doesn't rely on the hex conversion
The text was updated successfully, but these errors were encountered: