-
Notifications
You must be signed in to change notification settings - Fork 3.6k
fix(google): google provider codeExecution tool no longer treated as a client tool #11486
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
base: main
Are you sure you want to change the base?
fix(google): google provider codeExecution tool no longer treated as a client tool #11486
Conversation
|
Have you tested this on other gemini models other than gemini-3 series ? If not than please do and see, as before 3 series it wasn't possible to have structured output with provider defined tools. |
That hasn't changed. The user will receive the appropriate error from the API which is how it should work IMO |
Are you asking from the perspective of backward compatibility to models before Gemini 3 or getting them to work as well? |
|
Can you add your test code as an example under |
I added examples for both text output and structured output. My reasoning stems from the Google API treating the combination as a new feature for new models. |
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.
Additional Suggestion:
Comment on line 448 references old variable name 'hasToolCalls' instead of the renamed 'hasClientToolCalls'
View Details
📝 Patch Details
diff --git a/packages/google/src/google-generative-ai-language-model.ts b/packages/google/src/google-generative-ai-language-model.ts
index 69a86a393..5ddb1d5e3 100644
--- a/packages/google/src/google-generative-ai-language-model.ts
+++ b/packages/google/src/google-generative-ai-language-model.ts
@@ -445,7 +445,7 @@ export class GoogleGenerativeAILanguageModel implements LanguageModelV3 {
}
}
- // Process tool call's parts before determining finishReason to ensure hasToolCalls is properly set
+ // Process tool call's parts before determining finishReason to ensure hasClientToolCalls is properly set
if (content != null) {
// Process all parts in a single loop to preserve original order
const parts = content.parts ?? [];
Analysis
The PR renamed the variable 'hasToolCalls' to 'hasClientToolCalls' to distinguish between client tool calls and provider-executed tool calls. The variable is declared on line 383, modified on line 612, and passed to the finish reason mapping on line 621. However, the comment on line 448 still referenced the old variable name 'hasToolCalls'. This is a documentation inconsistency that could confuse code readers. The fix updates the comment on line 448 to correctly reference 'hasClientToolCalls' to match the actual variable name used throughout the code.
Background
Provider level tools calls do not need another step. The AI SDK was waiting for another step because it was treating it like a client tool call. So for structured outputs, the SDK was waiting for another step to parse the JSON.
Summary
hasToolCalls->hasClientToolCallsbecause provider tool calls do not need another step but client tools do!part.providerExecuted,) are added. The Gemini API is not consistent when the provider level tool call adds stuff toparts, (other provider tools do not), so this seemed the best way to handle that.(nowhasToolCallshasClientToolCalls) totrueduring provider level code executionManual Verification
Before (main):
After (PR branch):
Previously this only coincidentally worked if Gemini decided to complete the task without the code execution tool even though it was included. This is just non deterministic LLM stuff, the point is that it should also work when Gemini does use its provider side code execution tool.
Checklist
pnpm changesetin the project root)Related Issues
Fixes #11466