Context switching between Natchez and backend instrumentation

[bpholt]

Many of backends support auto-instrumentation for certain popular (non-Scala FP) libraries, typically using Java ThreadLocals to maintain the current span. If you're working in an app that has a tagless final / cats effect portion (where Natchez is a good fit) and also a non-FP Scala portion, it's not clear how best to propagate the span context between the two worlds in the same app.

I don't have a good solution for this, but if one exists, it would be nice to add it to the library, or at least document it. If one doesn't exist, that would also be good to document, so users can avoid frustration.

[dimitarg]

Not a contributor to this repository. It's a very broad question. I don't believe anything can solve this in full generality - we're working on a similar problem right now.I don't have anything working well yet. I think a starting point might be to use the opentelemetry backend - if your solution supports it - then at the boundary between your Natchez-aware code and auto-instrumented, obtain the "current" kernel / trace id and mess with contexts / executors, relying on the global opentelemetry instance. That's my game plan anyways.

[armanbilge]

I don't believe anything can solve this in full generality - we're working on a similar problem right now

Yes, I believe that's a good summary.

then at the boundary between your Natchez-aware code and auto-instrumented, obtain the "current" kernel / trace id and mess with contexts / executors,

We had some discussion on the Typelevel Discord, it should be solvable. The issue is nailing down the API to expose.

https://discord.com/channels/632277896739946517/839263556754472990/1072641756111306763

[mwisnicki]

This helps solving the problem: #1189