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
If your application receives a 128-bit trace ID, say from an x-b3-trace-id header, and then the application tries to report a span with it, reporting will fail because the Datadog agent expects a 64-bit Int for the trace ID. I discovered this a while ago and have since worked around it using a custom KamonDataDogTranslator, but I think the failure mode was that the DD agent discarded the reported trace because the trace ID was too large - it showed up in the DD agent logs.
Regardless, it seems like DdSpanReporter should use the lower 64 bits of a 128-bit trace ID. Lower, because, as a result of testing, I've determined that the official Datadog agent does the same when encountering a 128 bit trace ID in a B3 header, and you want Kamon to be compatible with a mixed environment using the Datadog agent as well.
The text was updated successfully, but these errors were encountered:
If your application receives a 128-bit trace ID, say from an
x-b3-trace-id
header, and then the application tries to report a span with it, reporting will fail because the Datadog agent expects a 64-bit Int for the trace ID. I discovered this a while ago and have since worked around it using a customKamonDataDogTranslator
, but I think the failure mode was that the DD agent discarded the reported trace because the trace ID was too large - it showed up in the DD agent logs.Regardless, it seems like DdSpanReporter should use the lower 64 bits of a 128-bit trace ID. Lower, because, as a result of testing, I've determined that the official Datadog agent does the same when encountering a 128 bit trace ID in a B3 header, and you want Kamon to be compatible with a mixed environment using the Datadog agent as well.
The text was updated successfully, but these errors were encountered: