When this feature is enabled (see `otel-mode?`), 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 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.
- Simplified some util name (only relevant to folks customizing handler behaviour)
- Merged `format-signal->edn-fn`, `format-signal->json-fn` to single `pr-signal-fn`
These seem to cause intermittent issues with GitHub actions. Seems like GHA might
be caching builds somehow, even when a caching action isn't present?
Can't reproduce locally, and haven't had an opportunity yet to identify or fix the
underlying cause, so just disabling these for now.
Thanks to @AdamFrey for reporting this issue!
Ref. <https://clojurians.slack.com/archives/C06ALA6EEUA/p1713805333272469>
Previously:
Attempting to run AOT'd code using Telemere would result in errors like:
"Attempting to call unbound fn: #'taoensso.telemere.handlers.open-telemetry/handler:open-telemetry-logger"
The approach I was using of conditionally requiring namespaces and then aliasing vars seems to be inherently
fragile under AOT, and was leading to the remote source var being unbound.
With this commit I've now switched to a simpler approach - where we conditionally require namespaces *without*
the need for any aliasing.
