Propagate OTEL trace id across client-workflow boundary#1601
Open
brianstrauch wants to merge 1 commit into
Open
Propagate OTEL trace id across client-workflow boundary#1601brianstrauch wants to merge 1 commit into
brianstrauch wants to merge 1 commit into
Conversation
The OTEL-aware OpenAI Agents interceptor propagated and seeded the OTEL span id but never the trace id, so the client-side root span and the workflow's reconstructed spans ended up in different traces. This made test_sdk_trace_to_otel_span_parenting flaky. Wire up the existing seed_trace_id so the workflow's root span reuses the caller's trace id.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The OTEL-aware OpenAI Agents interceptor (
_otel_trace_interceptor.py) propagated and seeded the OTEL span id across the client→workflow boundary (otelSpanId→seed_span_id), but never propagated the trace id. As a result the client-side "Client SDK trace" root span (created outside a workflow, so it gets a random trace id) and the workflow's reconstructed spans (created inside a workflow, so they get a deterministic workflow-random trace id) ended up in different traces.This made
test_sdk_trace_to_otel_span_parentingflaky: its "all spans belong to the same trace" assertion only failed when context-var timing caused the client-side root span to be exported and picked bynext(...), which is why it was intermittent on CI (example failure).Fix
Wire up the already-present-but-unused
seed_trace_id:header_contents: also emitotelTraceIdfrom the current span's context.context_from_header: callseed_trace_id(otel_trace_id)before the trace is reconstructed, so the workflow's root OTEL span reuses the caller's trace id.Now every span shares one trace id regardless of which root span the test selects — fixing the flake at its source rather than in the test.
Testing
tests/contrib/openai_agents/test_openai_tracing.pypasses (7/7), including the workflow→activity span-propagation cases. Ran the target test repeatedly to confirm stability.