-
-
Notifications
You must be signed in to change notification settings - Fork 744
fix: handle both ToolCall dataclass and OpenAI object in tool execution #769
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
After the OpenAI refactoring in PR #766, tool calls from streaming responses are ToolCall dataclass objects while non-streaming responses return OpenAI API objects. This fix handles both cases properly to prevent the "'dict' object has no attribute 'name'" error. Co-authored-by: Mervin Praison <MervinPraison@users.noreply.github.com>
|
Caution Review failedThe pull request is closed. WalkthroughThe update introduces support for handling tool calls represented as either OpenAI-style objects or as a new Changes
Sequence Diagram(s)sequenceDiagram
participant Agent
participant ToolCall (object/dict)
participant ToolExecutor
Agent->>ToolCall: Iterate tool_calls
alt ToolCall is dataclass
Agent->>ToolCall: Access function["name"], function["arguments"]
else ToolCall is OpenAI-style object
Agent->>ToolCall: Access function.name, function.arguments
end
Agent->>ToolExecutor: Execute tool with extracted name and arguments
Agent->>ToolCall: Access ID (attribute or key) for continuation logic
Possibly related PRs
Suggested labels
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
PR Reviewer Guide 🔍Here are some key observations to aid the review process:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summary of Changes
Hello @MervinPraison, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request resolves a critical bug in the agent's tool execution mechanism by introducing robust type handling for tool call objects. It ensures that the system can correctly interpret and process tool calls, regardless of whether they originate from streaming or non-streaming OpenAI API responses, thereby preventing attribute errors and enhancing the reliability of the agent's operations.
Highlights
- Bug Fix: Addressed a runtime error (
'dict' object has no attribute 'name') that occurred when processing tool calls, specifically due to inconsistencies in object types returned by the OpenAI API (ToolCall dataclass for streaming vs. OpenAI object for non-streaming responses). - Type Handling: Implemented conditional logic within the
_chat_completionmethod to correctly parsefunction_name,arguments, andtool_call_idby checking if thetool_callobject is aToolCalldataclass or a standard OpenAI API object. - Code Robustness: Ensured that the agent's tool execution logic is robust to variations in the structure of tool call objects received from the OpenAI API, improving overall stability.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
PR Code Suggestions ✨Explore these optional code suggestions:
|
||||||||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request correctly handles different types of tool call objects, preventing potential AttributeError exceptions. The changes look correct. I have included suggestions to improve maintainability and robustness.
| if isinstance(tool_call, ToolCall): | ||
| function_name = tool_call.function["name"] | ||
| arguments = json.loads(tool_call.function["arguments"]) | ||
| else: | ||
| function_name = tool_call.function.name | ||
| arguments = json.loads(tool_call.function.arguments) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| messages.append({ | ||
| "role": "tool", | ||
| "tool_call_id": tool_call.id, | ||
| "tool_call_id": tool_call.id if hasattr(tool_call, 'id') else tool_call['id'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For robustness, use isinstance to check the type of tool_call directly, instead of hasattr, before accessing its attributes.
| "tool_call_id": tool_call.id if hasattr(tool_call, 'id') else tool_call['id'], | |
| "tool_call_id": tool_call['id'] if isinstance(tool_call, dict) else tool_call.id, |
User description
After the OpenAI refactoring in PR #766, tool calls from streaming responses are ToolCall dataclass objects while non-streaming responses return OpenAI API objects. This fix handles both cases properly to prevent the "'dict' object has no attribute 'name'" error.
PR Type
Bug fix
Description
Fix tool call handling for both ToolCall dataclass and OpenAI objects
Prevent "'dict' object has no attribute 'name'" error
Add type checking for proper attribute access
Changes diagram
Changes walkthrough 📝
agent.py
Fix tool call object type handlingsrc/praisonai-agents/praisonaiagents/agent/agent.py
ToolCalldataclass vs OpenAI objectstool_call_idwith fallback for both object typesSummary by CodeRabbit