fix(ai-gemini): dedupe functionResponse parts by id, not name - #1198
fix(ai-gemini): dedupe functionResponse parts by id, not name#1198citizen204 wants to merge 3 commits into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 8 included reviews per hour; 6 remain after this review. 📝 WalkthroughWalkthroughThe Gemini adapter now deduplicates ChangesGemini tool response fix
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This is a localized Gemini response-deduplication fix with a regression test for parallel same-tool calls; no actionable merge-blocking risk remains beyond normal checks and review. Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
|
Thanks for the PR, @citizen204! 🙌 @AlemTuzlak will take a look. Automated pre-review checks
Automated triage — a human review follows. |
Two parallel calls to the same tool share a functionResponse.name but have distinct ids (msg.toolCallId, already set at both construction sites). mergeConsecutiveSameRoleMessages deduped by name, so the second response to a repeated same-tool call was dropped, leaving Gemini with fewer response parts than call parts on the next request: 400 INVALID_ARGUMENT: Please ensure that the number of function response parts is equal to the number of function call parts of the function call turn. Key the dedup on functionResponse.id instead — it still collapses a genuine duplicate tool result (same id twice), and now also preserves both responses when the model fires the same tool twice in one turn. Fixes TanStack#894
2544a39 to
3426899
Compare
Summary
When Gemini fires two or more parallel calls to the same tool in one turn,
mergeConsecutiveSameRoleMessagesdedupedfunctionResponseparts byname, so the second (and any further) response to a repeated same-tool call was silently dropped. Gemini requires exactly one response part per call part in a turn, so the next request 400s:Every
functionResponsealready carries a uniqueid(msg.toolCallId, set at both construction sites) — keying the dedup onidinstead keeps both parallel responses while still collapsing a genuine duplicate tool result (same id sent twice).Fixes #894
Changes
packages/ai-gemini/src/adapters/text.ts: dedupefunctionResponseparts byidinstead ofnameinmergeConsecutiveSameRoleMessages.packages/ai-gemini/tests/gemini-adapter.test.ts: regression test with two parallel calls to the same tool (distinct ids) — asserts bothfunctionResponseparts survive..changeset/gemini-parallel-tool-dedup.md: patch changeset.Ran the full
ai-geminisuite (vitest runinpackages/ai-gemini, after building its@tanstack/ai,@tanstack/ai-event-client,@tanstack/ai-utilsworkspace deps) — 325 passed, 18 files.Note: an earlier PR (#960) attempted this exact fix and was self-closed by its author for unrelated reasons ("keeping open PRs lean") after CodeRabbit review raised no substantive objections — the bug is still present on
main, so re-submitting with the same diagnosis plus a parallel-call regression test.Summary by CodeRabbit
Bug Fixes
Tests