Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is related to #734 and came from my investigations of that issue, though I'll note that I don't think merging this will resolve the issue.
Right now, when processing function tools, we increase the retry count for each unknown tool call received, which I think is incorrect behavior — I think we should increment the retry count at most once per response.
This PR currently makes that change, but that change causes a new issue — with the implementation in this PR, raising a
ModelRetry
contributes to the maximum model retry count, rather than just to the tool's retries. (The test I've left failing demonstrates the issue.)I'm not sure if I have surfaced a bug, and we should require you to increase the number of retries on
Agent
to avoid this raising theUnexpectedModelBehavior
exception, or if the pre-existing behavior was preferred.If the pre-existing behavior is preferred, I personally think the current distinction between treating unknown tool calls as incrementing the retry count, but tool calls that raise a
ModelRetry
not incrementing the retry count is rather confusing for end users (I mean, I was confused by it trying to understand what was happening in the example code). But even if you disagree with that, I definitely think the current implementation is confusing for developers — I've had to reverse engineer exactly what scenarios increment the retry count vs. not, and I think if I can get confirmation of the desired behavior, I can refactor the code to have that behavior (whatever it is) but also be easier to understand.