OTEL Tracing - Hierarchy inconsitency

[ThibaultCoudertSephora]

🔴 Required Information

Please ensure all items in this section are completed to allow for efficient
triaging. Requests without complete information may be rejected / deprioritized.
If an item is not applicable to you - please mark it as N/A

Describe the Bug:
When activating OTEL instrumentation (I used CloudTraceSpanExporter in my project), the parent_span_id management doesn't seem consistant across processing : the first LLM Call is linked to Agent, the Tool Execution is linked to Agent but the second LLM Call (post tool execution to format final answer) is linked to first LLM Call.

Steps to Reproduce:

1. Install google-adk 1.25.0 ; opentelemetry-api 1.38.0 ; opentelemetry-exporter-gcp-logging 1.11.0a0
2. Create an agent with a dummy tool and explain him when to call it.
3. Setup OTEL with span processor CloudTraceSpanExporter and activate BigQueryAgentAnalyticsPlugin
4. Launch adk web and start the conversation

Expected Behavior:
Let's say we have the following span generated:

• Span 1 = Agent invoked
• Span 2 = LLM Request
• Span 3 = Call LLM (with user input)
• Span 4 = Generate Content (Decide to use the tool)
• Span 5 = Tool Request
• Span 6 = Execute Tool
• Span 7 = LLM Request
• Span 8 = Call LLM (with tool output)
• Span 9 = Generate Content (Final answer to user)

I would either expect the Span 1 (Agent Invoked) to be the parent of Span 2 / Span 5 / Span 7 (fork as below) or Span 1 parent of Span 2 parent of Span 5 parent of Span 7 (full hierarchy)

Span 1 = Agent Invoked
|__ Span 2 = LLM Request
     |__ Span 3 = Call LLM
          |__ Span 4 = Generate Content
|__ Span 5 = Tool Request
     |__ Span 6 = Execute Tool
|__ Span 7 = LLM Request
     |__ Span 8 = Call LLM
          |__ Span 9 = Generate Content

Observed Behavior:
The second LLM Request (post tool invocation) is attached to first LLM Request, which lead to an inconsistent timeframe in Cloud Trace:

Span 1 = Agent Invoked
|__ Span 2 = LLM Request
     |__ Span 3 = Call LLM
          |__ Span 4 = Generate Content
     |__ Span 7 = LLM Request
          |__ Span 8 = Call LLM
               |__ Span 9 = Generate Content
|__ Span 5 = Tool Request
     |__ Span 6 = Execute Tool

Environment Details:

• ADK Library Version (pip show google-adk): 1.25.0
• Desktop OS:** [e.g., macOS, Linux, Windows] : Mac
• Python Version (python -V): Python 3.12

Model Information:

• Are you using LiteLLM: No
• Which model is being used: gemini-3-flash-preview

---

🟡 Optional Information

N/A*

Screenshots / Video:
N/A*

Additional Context:
N/A*

Minimal Reproduction Code:
N/A*

How often has this issue occurred?:

• Always (100%)

[ThibaultCoudertSephora]

I noticed this reported bug #4561 : please note that with adk version 1.25.1, the bug is still present. Besides, when removing the BigQueryAgentAnalyticsPlugin the logs behave differently in Cloud Trace :

• Some spans (LLM Request ; Invoke Tool) disappeared
• Span order is more consistent, but still not what I would expect : I don't get why the second LLM call is not a sibling of Execute Tool.

Span 1 = Agent Invoked
|__ Span 2 = Call LLM
     |__ Span 3 = Generate Content
     |__ Span 4 = Execute Tool
|__ Span 5 = Call LLM
          |__ Span 6 = Generate Content

Interested to have your thought on what should be the right hierarchy.

[surajksharma07]

@ThibaultCoudertSephora Two separate issues here: the BigQueryAgentAnalyticsPlugin corruption (second llm_request nested under the first) is caused by TraceManager.push_span() calling context.attach() on its internal spans, injecting them into the shared OTel context — this is already fixed in main post-1.25.1 (tracked in #4561), so upgrading when the next release drops should clear that up.

For the base case without the plugin, execute_tool nesting under call_llm is a contextvars leak: the with tracer.start_as_current_span('call_llm') block in base_llm_flow.py:1124 stays active when the generator yields, so _postprocess_async (which runs tool execution) inherits call_llm as its parent rather than invoke_agent.

Until there's a framework-level fix, you can work around it by monkey-patching BaseLlmFlow._call_llm_async to capture the parent context before the call and restore it with otel_context.attach(parent_ctx) / detach() around each yield — that restores invoke_agent as the ambient span during tool processing.

Both issues are reproducible 100% of the time on 1.25.1; the BQ plugin one will resolve on the future releases, the base one needs the upstream code change in base_llm_flow.py.