search

typelevel / natchez

functional tracing for cats
MIT License
323 stars 78 forks source link

Context switching between Natchez and backend instrumentation #706

Open bpholt opened 1 year ago

bpholt commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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