You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the Tracer internally (combines)[https://github.com/lightstep/lightstep-tracer-php/blob/master/lib/Client/Util.php#L32] two random int 32's into a string to create trace & span IDs, but then fails to correctly set that value when converting to the proto format (SpanContext’s SpanId & TraceId are unsigned int64 in proto - https://github.com/lightstep/lightstep-tracer-protos/blob/master/src/lightstep/collector/collector.proto#L14).
We regularly see values being set to 9223372036854775807, which is the PHP_INT_MAX on 64bit systems and leads to conflicts. Looking around on SO and similar, the general advice is to use strings instead of integers but I’m not sure how feasible it would be change the collector proto in this case.
I can force the IDs to be randomised between 0 and PHP_INT_MAX to be valid ints, however we’ll be working in a reduced range compared to other languages.
The text was updated successfully, but these errors were encountered:
PHP doesn’t support unsigned 64 bit integers, it does support signed 64 bit integers but is dependent on on the host platform - https://www.php.net/manual/en/language.types.integer.php
Currently the Tracer internally (combines)[https://github.com/lightstep/lightstep-tracer-php/blob/master/lib/Client/Util.php#L32] two random int 32's into a string to create trace & span IDs, but then fails to correctly set that value when converting to the proto format (SpanContext’s SpanId & TraceId are unsigned int64 in proto - https://github.com/lightstep/lightstep-tracer-protos/blob/master/src/lightstep/collector/collector.proto#L14).
We regularly see values being set to 9223372036854775807, which is the PHP_INT_MAX on 64bit systems and leads to conflicts. Looking around on SO and similar, the general advice is to use strings instead of integers but I’m not sure how feasible it would be change the collector proto in this case.
I can force the IDs to be randomised between 0 and PHP_INT_MAX to be valid ints, however we’ll be working in a reduced range compared to other languages.
The text was updated successfully, but these errors were encountered: