[Feat]: Propagate open telemetry context to agent execution for consolidated tracing

[vietk]

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

[vietk]

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]

@vietk I am really interested in this.. do you have something working? I am trying to achieve the same thing here.

[vietk]

Actually I think yes, I will open a Pull Request for sharing the implementation

[vietk]

@salaboy done

[salaboy]

@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]

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]

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]

We rely on CDI for the injection of the executorservice so in my opinion we could have that in the otel extra

[vietk]

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]

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?

I am in a similar situation here, I think this solution is good enough and framework agnostic.

[ehsavoie]

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]

@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?