Repository navigation
[Feat]: Propagate open telemetry context to agent execution for consolidated tracing #698
Description
Is your feature request related to a problem? Please describe.
Hello,
A2A Java SDK supports server OpenTelemetry thanks to OpenTelemetryRequestHandlerDecorator.
So far I managed to see sendMessage span in the traces in Tempo when I use sendMessage to my a2a application which is nice.
However, if I had my own custom span in an agent execution of my AgentExecutor, the whole trace is not consolidated with server span, it's 2 independent traces.
The main reason is that the server handling is executed inside a Vert.x router but the agent execution is done using a specific ExecutorService backed by A2A Internal executor.
Then, when the server handoff the execution to the agent executor, the opentelemetry context is not propagated and then is lost.
It results of having two different traces with their own spans and they are not linked at all.
- The server span in a trace (provided by a2a)
- My custom span in a trace
I would expect a single trace formed of two spans
Describe the solution you'd like
Opentelemetry context MUST be propagated between threads to ensure well formed traces with a valid parent span and the whole trace.
Since opentelemetry feature is not part of the server common modules, it's possible to define a SPI to implement for context propagation and implement it from the opentelemetry extra modules.
Describe alternatives you've considered
No response
Additional context
No response
Code of Conduct
- I agree to follow this project's Code of Conduct
Activity
vietk commentedon Mar 4, 2026
I was wondering if it's a bug or a feature, I opt for a feature :D
Would you agree if I contribute to this issue, I already have some code implementing the solution I described.
salaboy commentedon Mar 4, 2026
@vietk I am really interested in this.. do you have something working? I am trying to achieve the same thing here.
vietk commentedon Mar 4, 2026
Actually I think yes, I will open a Pull Request for sharing the implementation
feat: Add in-process context propagation for OpenTelemetry agent exec…
vietk commentedon Mar 4, 2026
@salaboy done
salaboy commentedon Mar 4, 2026
@vietk this is great.. checkout the gemini code comments.. I think if you add those improvements, I can take that code and test on my side too.
ehsavoie commentedon Mar 4, 2026
I'm wondering if the proper way would be to use a ManagedExecutorService instead so that context propagation would be managed by Quarkus itself
vietk commentedon Mar 4, 2026
I thought about the same, but I don't know exactly at which point the project should be tied to the Quarkus ecosystem and if you need portability (ex: spring boot?) even if CDI + Vertx Routes is already a big signal.
So yes, if I was sure of the orientation, I would have use ManagedExecutorService
ehsavoie commentedon Mar 4, 2026
We rely on CDI for the injection of the executorservice so in my opinion we could have that in the otel extra
vietk commentedon Mar 5, 2026
That would be a possibility.
But why limiting that to the OTEL extra module? that would make the module opinionated towards Quarkus and not usable for another framework like spring or helidon.
What you consider will be backed by a quarkus extension described in #370 and the proposal quarkiverse/quarkus-langchain4j#1994, but I think you are aware.
That would bring the best solution to support your idea and the framework isolation but many more (like a non-blocking agent execution 😉)
That being said, I need this fix/feature for a couple of internal demos so for a short term solution I think the SPI solution is good 😉, WDYT?
salaboy commentedon Mar 5, 2026
I am in a similar situation here, I think this solution is good enough and framework agnostic.
ehsavoie commentedon Mar 5, 2026
I tend to disagree, the ManagedExecutorService is not Quarkus specific but MP-Context-propagation or JakartaEE Concurrency (since JakartaEE11).
For Spring it is not clear but since it is not using CDI it would have to provide its own ExecutorService wrapper that would pass on the context.
salaboy commentedon Mar 5, 2026
@ehsavoie it would be awesome to have this included in Alpha4, I am using this with Quarkus, I am not sure @vietk , are you using this with Spring?
vietk commentedon Mar 5, 2026
I am using Quarkus as well
vietk commentedon Mar 5, 2026
Ah nice ! I thought it was a Quarkus feature, so I could revise my assessment.
But when I dig in MP context propagation I saw the spec was deprecated I haven't followed the JakartaEE concurrency track because it started to takes a bit of time on my side and decided another approach.
In this case I will try to find some time to revise my proposal
feat: propagate OTel context in async ops and fix TransportProtocol c…