While working on #1185 I checked if OpenTelemetry backend suffers from the same issue and it appeared it doesn't but I've spotted suspicious use of Context.current() like here and other places:
|
val ctx = otel.getPropagators.getTextMapPropagator.extract( |
|
Context.current(), |
|
kernel, |
|
spanContextGetter |
|
) |
Since Context.current() is implemented using ThreadLocal, with cats-effect this would return effectively random context.
According to extract documentation it will merge information extracted from the kernel with passed in context.
So the spanId/traceId will be correct but there is a risk of polluting context with other information from wrong thread (maybe coming from instrumentation agents or third party Java code that uses otel?).
Not sure how important this is in practice but I think Context should be propagated with OpenTelemetrySpan, created with Context.root() in entrypoints and also activated in #1189.
I don't really use it so I might be wrong.
While working on #1185 I checked if OpenTelemetry backend suffers from the same issue and it appeared it doesn't but I've spotted suspicious use of
Context.current()like here and other places:natchez/modules/opentelemetry/src/main/scala/natchez/opentelemetry/OpenTelemetrySpan.scala
Lines 214 to 218 in 784ddf9
Since
Context.current()is implemented usingThreadLocal, with cats-effect this would return effectively random context.According to
extractdocumentation it will merge information extracted from the kernel with passed in context.So the
spanId/traceIdwill be correct but there is a risk of polluting context with other information from wrong thread (maybe coming from instrumentation agents or third party Java code that uses otel?).Not sure how important this is in practice but I think
Contextshould be propagated withOpenTelemetrySpan, created withContext.root()in entrypoints and also activated in #1189.I don't really use it so I might be wrong.