Repository navigation
Fix/29365 duplicate tool responses - #29400
abhashkumar9051 wants to merge 3 commits into
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Summary of ChangesHello, 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 addresses an issue where Gemini CLI sessions resumed with the -r flag would generate duplicate functionResponse messages. By ensuring that durable user messages are treated as the source of truth and filtering out redundant or incorrect tool results during history reconstruction, the fix prevents backend rejection errors caused by mismatched function call and response counts. Additionally, it improves the isolation of parallel tool calls and stabilizes existing regression tests. Highlights
Using Gemini Code AssistThe 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 by creating a comment using either
Customization To customize the 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 Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
|
📊 PR Size: size/M
|
There was a problem hiding this comment.
Code Review
This pull request modifies the session history conversion and recording synchronization logic to prevent replaying duplicate tool results and sibling call responses during parallel tool execution. However, the feedback highlights that the current implementation of filtering tool call results by matching ID discards multi-modal sibling parts (such as inlineData or text parts). The reviewer recommends consolidating the filtering logic into a shared utility function that preserves these sibling parts, and restoring the corresponding test cases and assertions in chatRecordingService.test.ts to ensure multi-modal tool outputs are not lost.
| const matchingPart = (turn.content.parts || []).find( | ||
| (candidate) => candidate.functionResponse?.id === callId, | ||
| ); | ||
| if ( | ||
| JSON.stringify(tc.result) !== | ||
| JSON.stringify(turn.content.parts) | ||
| matchingPart && | ||
| JSON.stringify(tc.result) !== JSON.stringify([matchingPart]) | ||
| ) { | ||
| tc.result = turn.content.parts || []; | ||
| tc.result = [matchingPart]; |
There was a problem hiding this comment.
By using .find() and wrapping only the single matching functionResponse part in an array, any multi-modal sibling parts (such as inlineData or text parts returned by the tool) are completely discarded during history synchronization. This breaks multi-modal tool output preservation.
Instead, we should filter the parts to keep both the matching functionResponse and any non-functionResponse sibling parts. To avoid duplication and improve maintainability, this filtering logic should be consolidated into a shared utility function.
const matchingParts = filterToolParts(turn.content.parts || [], callId);
if (
matchingParts.length > 0 &&
JSON.stringify(tc.result) !== JSON.stringify(matchingParts)
) {
tc.result = matchingParts;
updated = true;
}References
- When adding new functionality, such as filtering, consolidate it with existing similar logic to avoid duplication and improve maintainability.
| functionResponseParts.push( | ||
| ...ensurePartArray(toolCall.result).filter( | ||
| (part) => part.functionResponse?.id === toolCall.id, | ||
| ), | ||
| ); |
There was a problem hiding this comment.
Filtering the toolCall.result array to only keep parts where part.functionResponse?.id === toolCall.id will discard any multi-modal sibling parts (such as inlineData or text parts) associated with the tool call. This causes multi-modal tool outputs to be lost when resuming a session.
We should update the filter to also preserve any non-functionResponse parts. To avoid duplication and improve maintainability, this filtering logic should be consolidated into a shared utility function.
functionResponseParts.push(
...filterToolParts(ensurePartArray(toolCall.result), toolCall.id),
);References
- When adding new functionality, such as filtering, consolidate it with existing similar logic to avoid duplication and improve maintainability.
| }); | ||
|
|
||
| it('should preserve multi-modal sibling parts during sync', async () => { | ||
| it('should sync only the matching function response during sync', async () => { |
There was a problem hiding this comment.
| expect(result).toHaveLength(1); | ||
| expect(result[0].functionResponse!.response).toEqual({ | ||
| output: maskedSnippet, | ||
| }); | ||
| expect(result[1].inlineData).toBeDefined(); | ||
| expect(result[1].inlineData!.mimeType).toBe('image/png'); | ||
| }); |
There was a problem hiding this comment.
Since we should preserve multi-modal sibling parts (like inlineData) during history synchronization, we should restore the original assertions of this test to verify that the sibling inlineData part is not discarded.
expect(result).toHaveLength(2);
expect(result[0].functionResponse!.response).toEqual({
output: maskedSnippet,
});
expect(result[1].inlineData).toBeDefined();
expect(result[1].inlineData!.mimeType).toBe('image/png');
});052fe11 to
ff6559e
Compare
ff6559e to
5dac544
Compare
|
Hi there! Thank you for your interest in contributing to Gemini CLI. To ensure we maintain high code quality and focus on our prioritized roadmap, we only guarantee review and consideration of pull requests for issues that are explicitly labeled as 'help wanted'. This PR will be closed in 7 days if it remains without that designation. We encourage you to find and contribute to existing 'help wanted' issues in our backlog! Thank you for your understanding. |
|
This pull request is being closed as it has been open for 14 days without a 'help wanted' designation. We encourage you to find and contribute to existing 'help wanted' issues in our backlog! Thank you for your understanding. |
Summary
Fixes duplicate
functionResponsemessages when resuming Gemini CLI sessions with-r.Tool results could be persisted both in
toolCalls[].resultand as durableusermessages. During session restoration, both copies could be replayed, causing duplicate function responses for the same function call ID.This can cause strict Gemini-compatible backends to reject the resumed request because the number of function responses does not match the number of function calls.
Details
The fix makes durable user
functionResponserecords the preferred source of truth during session restoration.Changes include:
convertSessionToClientHistory()now tracksfunctionResponseIDs already stored in user messages.toolCalls[].resultare only regenerated when a durable response for the same call ID does not exist.functionResponseparts with the same call ID are filtered during history reconstruction.Related Issues
Fixes #29365
How to Validate
Run the relevant test suites and verify that:
functionResponseparts.Validation performed:
Pre-Merge Checklist
realpathSyncto make PTY path resolution deterministic.Expected: 12, Received: undefined; after the test setup was corrected, it correctly identifies FD12, closes it, and returns12.