newrelic-java-agent VS natchez

Newrelic : https://github.com/newrelic/newrelic-java-agent/issues/605

https://github.com/newrelic/newrelic-java-agent/commit/3866b9ff3ffabf0d861f7b822257672b80168f52 This is how I implemented tracing for scala2.13 in new relic. You can't really end the trace in Future.map because that is actually a different Future. If open tracing is using the thread local you are not necessarily in the same thread or getting invoked right when the instrumented future finishes. I found the submit with value is always invoked when a Future is created and the run method surrounded everything that occurred within the Future body. I'm not familiar with open tracing, but my method is working well for my organizations scala apps.

Regarding real-world uses of this concept, I used it today to put natchez tracing in my http4s project. While the project is still small, I was shocked at the lack of invasiveness of this approach compared to usage of Kleisli to achieve the same effect.

It's never going to work with a ThreadLocal-based implementation because Future (and other Scala async stuff like cats.effect.IO) hop from thread to thread in an unpredictable way. The only way to do it is to jettison the magical "current span" thing and pass the span explicitly. You can hide this in the plumbing if you program with abstract effects (this is what Natchez Trace does) but with Future I think you're going to have to pass everything around in the open.