Potential bug in propagation of OpenTelemetry

[mwisnicki]

While working on https://github.com/typelevel/natchez/pull/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:

https://github.com/typelevel/natchez/blob/784ddf9d017c31e94f58d83a8049067f9a1d429d/modules/opentelemetry/src/main/scala/natchez/opentelemetry/OpenTelemetrySpan.scala#L214-L218

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 https://github.com/typelevel/natchez/pull/1189.

I don't really use it so I might be wrong.

[mwisnicki]

Actually unless something else called Context#makeCurrent there will be no current context so we get Context.root() every time we call Context.current().

Right now nothing in natchez calls makeCurrent but this would change with #1189. It's also possible for context to be created and made current by instrumentation agents for supported Java frameworks, for example when using http4s-netty.