typelevel
Add a variant of `Trace.ioTrace` that takes an existing IOLocal
In absence of a built-in IOLocal[A] => Local[IO, A] which would allow using natchezMtlTraceForLocal (might eventually be available if https://github.com/typelevel/cats-effect/pull/3429 ever gets merged and released), this would allow for some useful Java interop in a style similar to what otel4s suggests.
The ability to directly create (and thus, read afterwards) the IOLocal that holds the current span, lets some Java interop apply the following process:
- capture the current value in an effect
- downcast to a particular
Spanimplementation, e.g.DDSpan - extract the underlying java Span, e.g. the opentracing Span
- in a
delayblock, set the current span of the global Tracer instance to the span it just found.
I acknowledge this might not be a popular usecase (given nobody requested it by now), but it'd be quite helpful to my team at the moment.
I was going to suggest copying catsMtlEffectLocalForIO into natchez-mtl until it's adding to cats-effect, but maybe this is fine instead.
My main hesitation is that we'd want to be careful (both now and in the future) that this Trace[IO] doesn't do anything that can't be encoded using Local[IO, Span[IO]] semantics, since I think it's been concluded that Local semantics are safe, but using IOLocal directly can be dangerous in some scenarios? (See https://github.com/typelevel/cats-effect/issues/3385 for some additional discussion on this point. And to be clear, I'm sure @kubukoz has seen that, I'm just noting it for the record here.)
yeah, I would've liked to have Local[IO, E] at the ready and to implement this in terms of Local, but I'm hopeful that we can get https://github.com/typelevel/cats-effect/pull/3429 (or similar, but indeed a solution for https://github.com/typelevel/cats-effect/issues/3385) soon, and I wouldn't want there to be an implicit conflict. I guess we could keep the instance, and then un-implicit it when CE gets one of their own?
If we didn't want to publicly expose a copy of catsMtlEffectLocalForIO (although I do think including it here and then making it no longer implicit once it's available in cats-effect should be fine), one compromise would be to make a private copy and use that to implement def ioTraceLocal(local: IOLocal[Span[IO]]): Trace[IO]. Just brainstorming, really. 🤔
Sorry for the long wait, it's a busy time at work and I have no puter time left. I think you're right, we can always hide that implicit when there's an alternative with the same behavior.
no, think it's enough to use IOLocal + https://github.com/typelevel/natchez/blob/main/modules/mtl/shared/src/main/scala/package.scala, thanks for the ping