fix: provide unique toolUseId for gemini models
Description
The toolUseId field is supposed to provide an unique identifier of the tool use to the user, but it was instead filled with the tool name if user is using a Gemini model. Reason behind is that Gemini requires that name be set in the equivalent FunctionResponse type. Consequently, the current code assigns tool name to toolUseId in the tool use block.
As a solution, this PR proposes the following changes:
- create empty map
_tool_use_id_to_nameupon initialization - generate an unique id for the tool call in case "tool" and save to the map
- look up the function name from the map when constructing
FunctionResponse - clear the map at the beginning of each stream
Related Issues
#1200
Documentation PR
Type of Change
Bug fix
Testing
How have you tested the change? Verify that the changes do not break functionality or introduce warnings in consuming repositories: agents-docs, agents-tools, agents-cli
- [x] I ran
hatch run prepareprepare-results.txt
Checklist
- [x] I have read the CONTRIBUTING document
- [x] I have added any necessary tests that prove my fix is effective or my feature works
- [x] I have updated the documentation accordingly
- [x] I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
- [x] My changes generate no new warnings
- [x] Any dependent changes have been merged and published
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Last note, can you make sure to run hatch run prepare. I see there are some unit tests failing.
Last note, can you make sure to run
hatch run prepare. I see there are some unit tests failing.
yes, I finally got it working :) thank you
Codecov Report
:white_check_mark: All modified and coverable lines are covered by tests.
:loudspeaker: Thoughts on this report? Let us know!
@AirswitchAsa can you merge from main? There are some failing checks, and merge from main should fix those.
I'll approve the change as is. It won't get merged without passing approval workflows, and merge from main won't impact my approval