Problem:
(clojure.core.async/go (taoensso.telemere/log! "hello")) ; Compiles fine
(cljs.core.async/go (taoensso.telemere/log! "hello")) ; Compile fails
I could try to get to the bottom of exactly what's going on - but ultimately
IOC mechanisms like `go` are always going to be a bit fragile, especially for
heavily-optimized/unusual code.
In this case, the problem is thankfully only with Cljs - and Telemere's Cljs
performance isn't too critical - so I think we can afford to just bypass any
potential fiddling by the `go` macro by wrapping Cljs Telemere expansions in
an IIFE ((fn [] ...)).
Downside is the (small) added cost of a function construction and call.
Upside is avoiding potential issues with core.async and other similar
IOC-style systems (Electric Clojure, etc.)
Avoid repeatedly capturing the same callsite binding frame for each registered
handler. While the perf benefit of this change is minimal, the approach is also
conceptually cleaner.
When this feature is enabled (see `otel-tracing?`), Telemere's tracing
signal creators (`trace!`, `spy!`, etc.) will now manipulate OpenTelemetry's
span context when relevant.
Before this commit:
Telemere would detect and use OpenTelemetry span context, but
the inverse wasn't true: OpenTelemetry instrumentation wouldn't
recognize Telemere spans.
After this commit:
Telemere detects OpenTelemetry span context, and the inverse is
also true: OpenTelemetry instrumentation will recognize Telemere
spans.
The net effect:
When you use Telemere to trace forms that may themselves do
auto/manual OpenTelemetry instrumentation - the resulting spans
will now properly identify Telemere's spans as parents.
Note that this is interop is implemented in a unique way that retains
Telemere's usual benefits re: low costs at signal callsite, and ability
to skip costs when filtering / sampling / rate-limiting / etc.
