Repository navigation
OpenTelemetry contextvars leak across asynchronous generator boundaries in BaseAgent and Runner #5722
Description
Description
In Python asyncio, OpenTelemetry's default context propagation (tracer.start_as_current_span) relies on contextvars. In BaseAgent.run_async and Runner._run_with_trace, OpenTelemetry spans are created around asynchronous generator blocks (async for event in agen: yield event).
When multiple sub-agent coroutines yield and resume concurrently inside an asyncio.TaskGroup, contextvars can leak across coroutine boundaries if the OpenTelemetry span context is not explicitly detached before yielding. This causes child spans from one worker task to be incorrectly parented to the active span of a concurrent sibling task.
Proposed Solution
Explicitly manage OpenTelemetry context attachment and detachment around generator yield boundaries using context.attach and context.detach:
from opentelemetry import context, trace
span = tracer.start_span("invocation")
token = context.attach(trace.set_span_in_context(span))
try:
# ...
async for event in agen:
context.detach(token)
try:
yield event
finally:
token = context.attach(trace.set_span_in_context(span))
finally:
context.detach(token)
span.end()
Activity
surajksharma07 commentedon May 18, 2026
@chriskinzel explicitly managing context.attach/detach around yield boundaries is the right fix here.
One thing to validate though: context.detach() can throw ValueError when a task is cancelled mid-execution, which is actually why a similar approach was rolled back previously.
Could you confirm that #5725 wraps those detach calls in try/except ValueError and test it under both the parallel execution and task cancellation scenarios?
A thorough test pass before raising the PR for review would be ideal!
surajksharma07 commentedon May 29, 2026
@chriskinzel Going ahead and closing this out since there's been no follow-up in 2 weeks — just wanted to flag that the ValueError concern from my earlier comment turned out to be well-founded: the same context.attach/detach approach was actually applied internally (commit 60b9073) and then reverted two days later (ce113a8) because of exactly that cancellation edge case.
So #5725 will need to handle that scenario carefully before it's in a state to land without hitting the same revert — specifically, wrapping detach calls in try/except ValueError and verifying behavior when a task is cancelled mid-yield.
Feel free to reopen once #5725 has that covered and you've run it through the cancellation + parallel execution scenarios — happy to help push it over the line at that point!
fix: prevent contextvars leak across async generators