The :links option works with SpanContext (an object that contains span ID, trace ID and flags), but also has conveniences to extract the SpanContext from a span or context. Here is a minimal example that creates two spans, where the ::bar span contains a single link to the ::foo span:

(defn do-foo []
  (span/with-span! ::foo
    (span/with-span! {:name   ::bar
                      :parent nil
                      :links  [[(context/current)]]})))

Thanks!

So context/current should work. Here I sometimes don't get the "back links" in Aspire.Dashboard, despite the code definitely being executed. I'm trying to figure out what's going on. Thought maybe I am using the wrong context -- maybe it has bits of the wrong data... But I also get System.InvalidOperationException: Multiple traces found with trace id '31...'. in the console logs of Aspire.Dashboard. Maybe it's related...

The TextMapPropagator works with Context, not SpanContext. So I cannot just pass that instead, right?

TextMapPropagator are for reading and writing context information, usually as HTTP headers. I don't see the connection here with what you are trying to achieve.

I have a (custom) job queue. My goal is to apply https://opentelemetry.io/docs/specs/semconv/messaging/messaging-spans/ to it, which suggests to link to the message (job) creation context from the message (job) processing context. To do that I transport the creation context through the queue using TextMapPropagator. At the receiving end (when job processing starts) I want to extract the creation context from the job and set :links on the processing context. This already works in principle when using injecting context/current into my job in the "create" span and extracting it into context/current on the other side in the "process" span. But for some reason it sometimes does not work and the "process" span never shows up in Aspire.Dashboard. I wasn't able to figure out the pattern yet, so I am trying to figure out whether I am using all the tools correctly / within their spec.

The value of (context/dyn) will always be the same as (context/current) unless you are working with clj-otel bound context in async code, where you will set it yourself through various clj-otel functions. Think of bound context as an "override" of the current context for sections of async Clojure code.

But there are no automatisms using it, right?

I think the OTel java agent also does some magic to follow traces through asynchronous processing. (I think I saw some java agent code dealing with Executor or something like that.) Do you know whether this also applies to Clojure? Will automatic OTel traces also follow futures, agents, core.async and the likes?

I don't think there is any support for general Java/Clojure constructs provided by OpenTelemetry. Instead, its support is for specific Java libraries and frameworks.

From issues like https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/9324 and bits of code like: • https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/kotlinx-coroutines • https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/executors it seemed that there is some capability of instrumentation of asynchronous execution built into the java agent. But this is never automatic, and I always have to manually specify which thread pool / executor / ... to instrument?

Yes, this is what I mean by supporting specific libraries and frameworks. The design of the instrumentation requires knowledge of the program to be instrumented.

It does not work at a general level to work with all Java programs.

Ok, so if I wanted a trace to follow a certain future (e.g.) I would wrap that specific call to future with bind-context!? Or if I wanted no parent/child relationship, but only a link from within the future to the span where the future was originally spawned, I would use code like in your example in https://clojurians.slack.com/archives/C034UN5273N/p1722855379935119?thread_ts=1722851375.240269&cid=C034UN5273N ?

Or alternatively I could create some Context.taskWrapping(mySpecificExecutor) (or ExecutorService) and run my functions on that, but just for the functions where I want the context to follow them onto the executor's thread, not for all functions anywhere on my Clojure program that run on some thread pool (I assume a thread pool is an example for an executor)?

To work with asynchronous Clojure code, you can use bound or explicit context passing. A future will convey the bound context as you suggest.

I haven't added support for Executor in clj-otel, I have not looked at them in detail. From what I understand there are some facilities in OpenTelemetry Java to set the current context in the executed tasks.

> there are some facilities in OpenTelemetry Java to set the current context in the executed tasks Yes, that's how I read the code, too: https://github.com/open-telemetry/opentelemetry-java/blob/6fc1d216ca0f199670a1cc5b081ad764d4a043fb/context/src/main/java/io/opentelemetry/context/Context.java#L119-L121