fix(ai): wrap unparseable tool call input in object to prevent provider rejection#16539
Open
FrancoKaddour wants to merge 3 commits into
Open
fix(ai): wrap unparseable tool call input in object to prevent provider rejection#16539FrancoKaddour wants to merge 3 commits into
FrancoKaddour wants to merge 3 commits into
Conversation
…d server_error with zod v4
Recurse only through known JSON Schema structural keywords (properties, patternProperties, \, allOf, anyOf, etc.) instead of every object key. Prevents deletion of user-defined tool or response parameters whose name happens to be 'pattern'.
…jection
When a tool call's input is not valid JSON, the catch block fallback
stored toolCall.input (a raw string) directly as the tool call's input
field. On multi-turn conversations this raw string ends up in the
message history. Providers like Amazon Bedrock expect toolUse.input to
be a JSON object and reject the request with a format error on the
next turn.
Fix: when safeParseJSON fails, store { rawInvalidInput: toolCall.input }
so the field is always a JSON-serialisable object.
Fixes vercel#14442
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
| name: tool.name, | ||
| description: tool.description, | ||
| parameters: tool.inputSchema, | ||
| parameters: removePatternKeyword(tool.inputSchema), |
Contributor
There was a problem hiding this comment.
removePatternKeyword returns unknown, which is not assignable to the strongly-typed parameters: JSONSchema7 field of OpenAIResponsesFunctionTool, causing a tsc type error that breaks the build.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Fixes #14442
When a tool call's input cannot be parsed as JSON, the catch block in parseToolCall falls back to storing toolCall.input (a raw string) as the input field of the returned tool call object. In multi-turn conversations this raw string ends up in the message history. Providers like Amazon Bedrock expect toolUse.input to be a JSON object and reject the next request with:
The format of the value at messages.X.content.Y.toolUse.input is invalid.
Fix: when safeParseJSON fails, store { rawInvalidInput: toolCall.input } so the field is always a JSON-serialisable object regardless of what the model returned. The original invalid string is preserved inside the wrapper for debugging.
Updated the two existing inline snapshot tests that asserted "input": "invalid json" to reflect the new shape.