LLM Observability context lost when using Kitlin coroutines
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 38/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Domain
- backend, observability
Research direction
Start with ThreadLocalContextManager.java and the DDLLMObsSpan.java constructor to trace how LLMObsState reads and attaches context. Review the existing Kotlin coroutine instrumentation and reproduce the issue with the provided parallel Dispatchers.IO scenario. Done means child LLM spans created after suspension retain the expected parent span IDs and hierarchy.
Written by the indexing model from the issue text.
Description
Tracer Version(s)
1.58.2
Java Version(s)
21.0.7
JVM Vendor
Amazon Corretto
Bug Report
LLM Observability context lost when using Kotlin coroutines
When using LLM Observability with Kotlin coroutines, the LLMObsState context is lost when coroutines suspend and resume on different threads. This breaks parent-child span relationships and can cause spans to have incorrect or missing parent IDs.
Environment
- dd-trace-java version: 1.58.2
- Kotlin with coroutines
- Spring WebFlux / suspend functions
Root Cause
LLMObsState relies on datadog.context.Context which is backed by ThreadLocalContextManager:
// ThreadLocalContextManager.java
final class ThreadLocalContextManager implements ContextManager {
private static final ThreadLocal<Context[]> CURRENT_HOLDER =
ThreadLocal.withInitial(() -> new Context[] {EmptyContext.INSTANCE});
@Override
public Context current() {
return CURRENT_HOLDER.get()[0]; // Plain ThreadLocal - not coroutine-safe
}
}
When DDLLMObsSpan is created, it attaches to the current context and sets the parent:
// DDLLMObsSpan.java constructor
AgentSpanContext parent = LLMObsState.getLLMObsParentContext(); // Returns null on different thread
// ...
this.scope = LLMObsState.attach();
LLMObsState.setLLMObsParentContext(this.span.context());
Impact
This is particularly problematic for:
- Batch LLM operations (parallel embeddings, parallel completions)
- Agent workflows with parallel tool execution
- Any async/concurrent LLM workloads using Kotlin coroutines or reactive frameworks such as Spring WebFlux
Potential Solutions
-
Leverage existing Kotlin coroutine instrumentation - dd-trace-java has coroutine support for APM traces. Could similar context propagation be applied to
LLMObsState? -
Use
CoroutineContextelements - Allow users to propagate LLM Obs context explicitly via coroutine context, similar to how MDC context can be propagated. -
Integrate with
datadog.context.Contextpropagation - If there's existing machinery for propagatingContextacross async boundaries, ensureLLMObsStatebenefits from it.
Contribution
I would be happy to contribute a fix for this if the approach is welcomed. Please let me know the preferred direction and any guidance on implementation.
Expected Behavior
Child LLM spans created within coroutines should correctly reference their parent span, maintaining the trace hierarchy.
Actual Behavior
LLMObsState.getLLMObsParentContext()returnsnullwhen called from a different thread- Child spans get
parent_id="undefined"instead of the actual parent span ID - Trace hierarchy is broken in the Datadog LLM Observability UI
Reproduction Code
Reproduction Scenario
// Parent span created on Thread-1
val parentSpan = LLMObs.startAgentSpan("agent", mlApp, sessionId)
coroutineScope {
// Child spans created in parallel coroutines
// These may run on Thread-2, Thread-3, etc.
listOf(task1, task2, task3).map { task ->
async([Dispatchers.IO](http://dispatchers.io/)) {
// LLMObsState.getLLMObsParentContext() returns null here
// because ThreadLocal from Thread-1 is not available
val childSpan = LLMObs.startLLMSpan("llm.inference", model, provider, mlApp, sessionId)
// ... do work
childSpan.finish()
}
}.awaitAll()
}
parentSpan.finish()
- Dominant language
- Java
- Stars
- 737
- Forks
- 361
- Avg merge
- 3d 20h
- Merged PRs (30d)
- 173
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from DataDog/dd-trace-java
-
type: feature request
Difficulty 1/5 1-3 hours Newbie friendliness 70/100
DataDog/dd-trace-java#10245 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 62/100
DataDog/dd-trace-java#12608 ·
-
type: bug report
Difficulty 4/5 3-5 days Newbie friendliness 35/100
DataDog/dd-trace-java#12597 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
DataDog/dd-trace-java#12540 · 3 comments · 1 assignee ·
-
Difficulty 3/5 1-2 days Newbie friendliness 25/100
DataDog/dd-trace-java#12480 ·
All issues in DataDog/dd-trace-java
Similar issues
-
certification
Difficulty 1/5 Under an hour Newbie friendliness 80/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
[BUG] ECR GetAuthorizationToken returns a proxyEndpoint for the default region, not the request's Openbug ecr
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Needs: Triage Type: Feature request
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
AntennaPod/AntennaPod#8794 ·
-
agentic-workflows
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
github/copilot-sdk#2760 ·