Skip to content

fix: give parallel Gemini tool calls distinct tool_use ids - #151

Merged
lich0821 merged 1 commit into
lich0821:masterfrom
pcbeingused333:fix/gemini-duplicate-tool-ids
Oct 27, 2026
Merged

lich0821 merged 1 commit into
lich0821:masterfrom
pcbeingused333:fix/gemini-duplicate-tool-ids

Conversation

@pcbeingused333

Copy link
Copy Markdown
Contributor

When Gemini is the upstream, GeminiRespToClaude and GeminiStreamToClaude built every tool_use id as call_<function name>. Gemini sends no call ids, so two calls to the same tool in one turn (parallel read_file calls, for instance) came back with identical ids, and Claude Code could not tell which tool_result belongs to which call.

Both paths now use newGeminiToolUseID(), which returns call_ plus a UUID. The id-to-name map used when the history is converted back (convertClaudeContentToGeminiParts) still resolves the function name from the id, so the functionResponse keeps the right name.

New tests send a Gemini response with two read_file calls through the non-streaming and the streaming conversion and require two distinct ids. Both fail on master (both ids are call_read_file) and pass with the change, together with the rest of ./internal/transformer/.... Not run against the live Gemini API.

This change was prepared with AI assistance (Claude Code).

🤖 Generated with Claude Code

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
@lich0821
lich0821 merged commit 9b07bab into lich0821:master Oct 27, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants