Expose child Spans from OpenTracing API to support tracing legacy code?

[kalexmills]

I have a use-case where we're using http4s to drive legacy code written in Java (which we're not ready to rewrite in the typelevel style).

I would like to be able to share a trace initiated from http4s via natchez (and code written in #5) to pass down a child OpenTracing Span to serve as the root span of my legacy Java calls.

I realize this breaks the nice abstraction / hiding provided by natchez, but there can be reasons for consenting adults to do so from time-to-time.

Are we open to adding extension methods to the entrypoint hooks (like in JaegerTracer) to construct and return a child span from the OpenTracing API, or would that ruin everything?

[kalexmills]

Mkay, so this can be done.

Trace[F].kernel yields a Map[String, String] which you can just use to reconstruct a new span using whatever fancy mechanism you want.

👍

[tpolecat]

The contents of the map are only meaningful to Natchez, so I would not count on being able to inspect it and pull out usable data.

If you have access to your Span[F] you can try to downcast it to JaegerSpan which gives you access to the underlying span and tracer. If all you have is Trace[F] then you're out of luck unless we give you a way to surface the current span (which we could).

In general this seems bad because as you say it breaks the abstraction, and if you change your tracing back end it will break code that assumes a particular implementation.

[kalexmills]

Having a way to surface the current span could be useful in one of maybe a few different ways.

[mwisnicki]

This can help with interop: #1189