feat: implement tool calling support for workflow API #20
Conversation
- Add ToolCall, ToolCallFunction, ToolFunction, and Tool types to tracing_types.go
- Extend Message type with ToolCalls field for tool calling support
- Add Tools field to Prompt type for function definitions
- Implement setMessageToolCallsAttribute and setToolsAttribute functions
- Update setMessagesAttribute to handle tool calls with individual span attributes
- Create comprehensive tool calling sample with workflow API
- Support multi-turn tool calling conversations with proper tracing
- Set individual span attributes matching Python OpenLLMetry implementation:
- llm.completions.{i}.tool_calls.{j}.id
- llm.completions.{i}.tool_calls.{j}.name
- llm.completions.{i}.tool_calls.{j}.arguments
- llm.request.functions.{i}.name
- llm.request.functions.{i}.description
- llm.request.functions.{i}.parameters
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
WalkthroughThe changes introduce a tool-calling example workflow in the sample application, integrating Traceloop tracing and OpenAI APIs. The Traceloop SDK and its types are extended to support tool and tool call metadata. The sample app's dependencies are expanded and local module replacements added. An older workflow example is deleted. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant MainApp
participant TraceloopSDK
participant OpenAI
User->>MainApp: Run with "tool-calling" argument
MainApp->>TraceloopSDK: Initialize tracing
MainApp->>OpenAI: Send chat completion with tool (weather)
OpenAI->>MainApp: Return assistant response (with tool calls)
MainApp->>TraceloopSDK: Log assistant response and tool calls
MainApp->>MainApp: Parse tool calls, run getWeather
MainApp->>TraceloopSDK: Log tool results
MainApp->>OpenAI: Send follow-up chat completion with tool results
OpenAI->>MainApp: Return final assistant response
MainApp->>TraceloopSDK: Log final response
MainApp->>User: Print results
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~18 minutes Poem
Note 🔌 MCP (Model Context Protocol) integration is now available in Early Access!Pro users can now connect to remote MCP servers under the Integrations page to get reviews and chat conversations that understand additional development context. ✨ Finishing Touches
🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![ellipsis-dev[bot]](https://avatars.githubusercontent.com/in/64358?s=60&v=4){kind=small}
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed everything up to de1ead2 in 1 minute and 20 seconds. Click for details.
- Reviewed
773lines of code in7files - Skipped
0files when reviewing. - Skipped posting
3draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. traceloop-sdk/sdk.go:117
- Draft comment:
In the setToolsAttribute function, the error from json.Marshal is silently ignored. Consider logging or otherwise handling the error (lines 117–123) to aid in debugging parameter serialization issues. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% This is a tracing/observability function that sets span attributes. If serialization fails, the code gracefully degrades by simply not setting that particular attribute. Since this is non-critical observability code, silent failure might be acceptable. However, having no indication of serialization failures could make debugging issues harder. I might be underestimating the impact of missing parameter data in traces. Also, json.Marshal errors are rare but could indicate deeper issues with the data structure. While logging the error could help debugging, the current behavior of graceful degradation is reasonable for observability code. The parameters attribute is optional metadata. The comment raises a valid point but the current implementation is acceptable given this is non-critical observability code. The comment should be removed as it doesn't highlight a significant issue requiring change.
2. sample-app/main.go:100
- Draft comment:
The conversion functions (convertOpenAIToolCallsToTLP and convertToolsToTLP) are straightforward and correctly implemented; however, adding inline documentation and unit tests could improve clarity and maintainability. - Reason this comment was not posted:
Confidence changes required:40%<= threshold50%None
3. traceloop-sdk/sdk.go:174
- Draft comment:
In the Shutdown function, tracerProvider.Shutdown is invoked without capturing its error. Consider capturing and logging any error returned to ensure shutdown issues are not silently ignored. - Reason this comment was not posted:
Confidence changes required:40%<= threshold50%None
Workflow ID: wflow_IYFjcZwhxz9QFyBm
You can customize 
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
sample-app/main.go (1)
17-22: Nil-pointer risk whenNewClientfails
defer func() { traceloop.Shutdown(ctx) }()is executed before you checkerr.
IfNewClientreturns an error,traceloopisniland the deferred call panics.Move the defer after the error check:
-traceloop, err := tlp.NewClient(ctx, tlp.Config{ ... }) -defer func() { traceloop.Shutdown(ctx) }() -if err != nil { +traceloop, err := tlp.NewClient(ctx, tlp.Config{ ... }) +if err != nil { fmt.Printf("NewClient error: %v\n", err) return } +defer func() { traceloop.Shutdown(ctx) }()
♻️ Duplicate comments (1)
sample-app/main.go (1)
170-175: Same nil-pointer panic pattern hereReplicate the fix inside
runToolCallingExample()for the secondNewClientcall.
🧹 Nitpick comments (4)
traceloop-sdk/tracing_types.go (1)
20-23: Exported type lacks JSON “omitempty” safeguard
Tool.Functionwill always serialize the emptyfunctionobject even when no data are provided.
If you want the field to be truly optional (consistent withtool_callsandtools), addomitempty:-type Tool struct { - Type string `json:"type"` - Function ToolFunction `json:"function"` +type Tool struct { + Type string `json:"type"` + Function ToolFunction `json:"function,omitempty"` }traceloop-sdk/sdk.go (2)
80-89: Missing propagation oftoolCall.Type
setMessageToolCallsAttributerecordsid,name, andargumentsbut drops the tool-calltypeeven though this value is available in the struct.
If multiple tool-call types are ever introduced, observability will be incomplete.attribute.String(toolCallPrefix+".arguments", toolCall.Function.Arguments), +attribute.String(toolCallPrefix+".type", toolCall.Type),
117-124: Silent JSON-marshal failure hides problemsIf
json.Marshalontool.Function.Parameterserrors, the SDK swallows it and emits no attribute, silently degrading telemetry.
At minimum log the error so integrators know something is wrong:- if tool.Function.Parameters != nil { - parametersJSON, err := json.Marshal(tool.Function.Parameters) - if err == nil { - span.SetAttributes(attribute.String(prefix+".parameters", string(parametersJSON))) - } - } + if tool.Function.Parameters != nil { + if parametersJSON, err := json.Marshal(tool.Function.Parameters); err == nil { + span.SetAttributes(attribute.String(prefix+".parameters", string(parametersJSON))) + } else { + log.Printf("traceloop: failed to marshal tool parameters: %v", err) + } + }sample-app/main.go (1)
269-286: Default unit assignment bypasses schema enumAssigning
"F"whenunitis empty is fine, but if the assistant explicitly passes an empty string, the result silently changes.
Consider validatingparams.Unitagainst the enum (C|F) and returning an error to the model instead of coercing.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
go.work.sumis excluded by!**/*.sumsample-app/go.sumis excluded by!**/*.sum
📒 Files selected for processing (5)
sample-app/go.mod(1 hunks)sample-app/main.go(2 hunks)sample-app/workflow_example.go(0 hunks)traceloop-sdk/sdk.go(3 hunks)traceloop-sdk/tracing_types.go(2 hunks)
💤 Files with no reviewable changes (1)
- sample-app/workflow_example.go
🧰 Additional context used
🧬 Code Graph Analysis (1)
traceloop-sdk/sdk.go (2)
traceloop-sdk/tracing_types.go (3)
ToolCall(8-12)Message(25-30)Tool(20-23)semconv-ai/attributes.go (1)
LLMRequestFunctions(25-25)
🔇 Additional comments (1)
sample-app/go.mod (1)
11-23: Duplicate major versions of the same libraryBoth
github.com/cenkalti/backoff(v2) andgithub.com/cenkalti/backoff/v4are required.
Having two major versions of the same package inflates the build and usually indicates an unintended transitive dependency.
Rungo mod tidyand, if possible, align downstream libs to a single major version.
🤖 Generated with Claude Code
Important
Implement tool calling support in workflow API with new types, functions, and a sample application.
ToolCall,ToolCallFunction,ToolFunction, andTooltypes totracing_types.gofor tool calling support.Messagetype withToolCallsfield andPrompttype withToolsfield.setMessageToolCallsAttributeandsetToolsAttributefunctions insdk.go.setMessagesAttributeinsdk.goto handle tool calls.main.gowith multi-turn conversation support.sdk.goto match Python OpenLLMetry implementation.go.work.sum,go.mod, andgo.sumfor tool calling support.This description was created by
for de1ead2. You can customize this summary. It will automatically update as commits are pushed.
Summary by CodeRabbit
New Features
Improvements
Removals