Repository navigation
fix(observability): propagate W3C traceparent on outbound LLM requests - #49046
Closed
joshreini1 wants to merge 2 commits into
Closed
joshreini1 wants to merge 2 commits into
joshreini1 wants to merge 2 commits into
Conversation
Inject traceparent/tracestate headers from the active OTel span context into every outbound LLM provider HTTP request. This allows an OTLP-capable server (AI gateway, observability proxy) to create a child span linked to the caller's trace, producing a single connected trace. The injection happens in the request executor layer: before http.execute(), the global OTel propagator writes trace context headers into the request. When no span is active (tracing not configured), propagation.inject() is a no-op and no headers are added. Closes anomalyco#49038 Relates to anomalyco#46856
Contributor
|
Hey! Your PR title Please update it to start with one of:
Where See CONTRIBUTING.md for details. |
Contributor
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
1 task done
… provider fetch The previous approach injected traceparent in packages/llm/src/route/executor.ts, but that layer is not on the path LLM requests take. Two problems, both fixed here: 1. No propagator was registered. propagation.inject() falls back to a no-op propagator when none is set, so the carrier came back empty and no headers were ever written. tracingLayer() now registers a W3C trace context propagator alongside the existing context manager. 2. Wrong injection point. AI SDK providers issue requests through the provider fetch wrapper in provider.ts, not the Effect HTTP client in executor.ts. Injection moved to the fetch wrapper so it covers every provider. Reverts the executor.ts and packages/llm/package.json changes, which are no longer needed. Verified against a live OTLP gateway: gateway server spans now carry the client trace_id and parent to the ai.streamText.doStream span.
Author
|
@rekram1-node can you take a look? |
Member
|
This branch has been upgraded to V2. We're no longer taking PRs for V1. If you think this is still relevant, please port it over and open it for V2. — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊 |
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
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.
Issue for this PR
Closes #49038
Type of change
What does this PR do?
Makes OpenCode propagate W3C trace context on outbound LLM requests, so an OTLP-capable gateway or proxy can parent its server span to the client span instead of starting a disconnected trace.
Two changes:
packages/core/src/observability/otlp.ts— register a W3C trace context propagator.tracingLayer()already set a global context manager, but never set a propagator.propagation.inject()falls back to a no-op propagator when none is registered, so it silently wrote nothing. This is why no trace headers were being sent.packages/opencode/src/provider/provider.ts— inject the trace context in the providerfetchwrapper (~line 1822), which every AI SDK provider request passes through.@opentelemetry/apiis already a dependency of this package.When
experimental.openTelemetryis off orOTEL_EXPORTER_OTLP_ENDPOINTis unset,tracingLayer()returnsLayer.empty, no propagator is registered, andpropagation.inject()writes nothing. The request goes out with identical headers. No behavioral change for users without tracing.How did you verify your code works?
tsc --noEmit -p packages/opencode/tsconfig.jsonreports no errors in either changed file.Ran a real
opencode runsession (LLM calls plus a bash tool call) against a live OTLP gateway withexperimental.openTelemetry: trueandOTEL_EXPORTER_OTLP_ENDPOINTset, then queried the gateway trace table. Gateway server spans now share the client trace_id and parent to the client span:Each server span's
parent_span_idmatches the span id from thetraceparentheader sent on that request. Before the fix, the same session produced client spans in one trace and each gateway server span in its own separate single-span trace.A second session reproduced this with 6 server spans in a 2413-span trace.
Checklist