Duplicate Trace Entries in Tool Calls: Insights and Solutions

Ranjit P. · 2025-05-13T03:29:25.936Z

Hi, I am seeing duplicate entries for traces , with default configuration i was seeing parent level traces however sub tool calls / internal function calls were missing however post adding decorators the sub tools calls got tracked however multiple traces for same sub tool calls being seen. Please refer to below attached images. The expected output also attached which is tracked using mlflow. load_chroma_db and query_top_chunks were traceable after adding decorators however you can see rag tool twice tracked.

Duplicate Trace Entries in Tool Calls: Insights and Solutions | Arize AI Community

13 comments

· Sorted by Oldest

RunLLM
APP
·
Duplicate traces for sub-tool calls (like seeing the same tool span twice) often occur when both auto-instrumentation and manual instrumentation (e.g., decorators) are applied simultaneously, or when multiple instrumentors are active for the same function/class. This can cause Phoenix to register the same operation more than once, resulting in duplicate spans for tools or internal function calls. The official guidance is to use either auto-instrumentation or manual decorators, but not both for the same code path, to avoid this issue. Additionally, ensure that only one relevant instrumentor is active for each library or function—using both, for example, LlamaIndex and OpenAI instrumentors together can also cause double-counting or duplicate spans (source, source).To resolve this, review your code and remove redundant decorators or instrumentors, ensuring each function or tool is only instrumented once. If you want to track sub-tool calls, use decorators only on those specific functions and avoid global auto-instrumentation for the same library. Would you like a step-by-step example of how to configure this correctly?Sources: - Phoenix Issue: Double Counting and Duplicate Spans - Phoenix Docs: Instrument Python
💡 Hint: Mention RunLLM in the thread for followups.
Ranjit P.
·
Tried the same, however no luck.
Ranjit P.
·
I have double checked my code and i think there is no such double configurations which could cause duplicate traces . Still i am finding duplication. Any other resolution?
Ranjit P.
·
Hi 🔒[private user], I have tried with auto instrumentation and then tried with langchain instrumentation followed by disabling auto instrumentation. And the sub tool calls were not being captured. Then i have added decorators and now the sub tool calls being tracked but duplicate entries being shown.
Ranjit P.
·
The rag_tool one is duplicate one. If you see another screenshot where i have used MLFLOW which is expected one.
Ranjit P.
·
yeah, cause in mlflow in decorator i gave the rag_tool() as Rag Tool, thats why you are seeing them. Same here in phoenix i gave rag_tool() name as rag tool in decorator, however it is showing differently, not grouping them.
Ranjit P.
·
What is the resolution here to have same trace structure as mlflow? 🔒[private user] If you need i can share my code with you .
Ranjit P.
·
Yeah sure. Please check pinged you the code file.
👍1
Ranjit P.
·
i was exploring both way defining decorators like, @tracer.tool()/@tracer.agent() etc and @tracer.start_as_current_span()
Ranjit P.
·
No problem 🔒[private user]. Thanks for your help.
Ranjit P.
·
Hi 🔒[private user] Please do let me know if there is update on this. Thanks
Ranjit P.
·
ok, cool.
Ranjit P.
·
Hi 🔒[private user] any update

RunLLM
APP
·
Duplicate traces for sub-tool calls (like seeing the same tool span twice) often occur when both auto-instrumentation and manual instrumentation (e.g., decorators) are applied simultaneously, or when multiple instrumentors are active for the same function/class. This can cause Phoenix to register the same operation more than once, resulting in duplicate spans for tools or internal function calls. The official guidance is to use either auto-instrumentation or manual decorators, but not both for the same code path, to avoid this issue. Additionally, ensure that only one relevant instrumentor is active for each library or function—using both, for example, LlamaIndex and OpenAI instrumentors together can also cause double-counting or duplicate spans (source, source).To resolve this, review your code and remove redundant decorators or instrumentors, ensuring each function or tool is only instrumented once. If you want to track sub-tool calls, use decorators only on those specific functions and avoid global auto-instrumentation for the same library. Would you like a step-by-step example of how to configure this correctly?Sources: - Phoenix Issue: Double Counting and Duplicate Spans - Phoenix Docs: Instrument Python
💡 Hint: Mention RunLLM in the thread for followups.
Ranjit P.
·
Tried the same, however no luck.
Ranjit P.
·
I have double checked my code and i think there is no such double configurations which could cause duplicate traces . Still i am finding duplication. Any other resolution?
Ranjit P.
·
Hi 🔒[private user], I have tried with auto instrumentation and then tried with langchain instrumentation followed by disabling auto instrumentation. And the sub tool calls were not being captured. Then i have added decorators and now the sub tool calls being tracked but duplicate entries being shown.
Ranjit P.
·
The rag_tool one is duplicate one. If you see another screenshot where i have used MLFLOW which is expected one.
Ranjit P.
·
yeah, cause in mlflow in decorator i gave the rag_tool() as Rag Tool, thats why you are seeing them. Same here in phoenix i gave rag_tool() name as rag tool in decorator, however it is showing differently, not grouping them.
Ranjit P.
·
What is the resolution here to have same trace structure as mlflow? 🔒[private user] If you need i can share my code with you .
Ranjit P.
·
Yeah sure. Please check pinged you the code file.
👍1
Ranjit P.
·
i was exploring both way defining decorators like, @tracer.tool()/@tracer.agent() etc and @tracer.start_as_current_span()
Ranjit P.
·
No problem 🔒[private user]. Thanks for your help.
Ranjit P.
·
Hi 🔒[private user] Please do let me know if there is update on this. Thanks
Ranjit P.
·
ok, cool.
Ranjit P.
·
Hi 🔒[private user] any update