Repository navigation
Conversation
…ropic Messages Signed-off-by: Nicolas Languille <[email protected]>
github-actions
Bot
added
the
needs:compliance
|
The following comment was made by an LLM, it may be inaccurate: |
github-actions
Bot
removed
the
needs:compliance
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
|
whenever this PR gets accepted, I leave to maintainers responsibility to update the branch once the time comes. :-) |
![opencode-agent[bot]](https://avatars.githubusercontent.com/in/1549082?s=60&v=4){kind=small}
There was a problem hiding this comment.
The fix works. I compiled an Anthropic Messages request whose history holds a provider-executed read (and tool_search_tool_regex) call/result pair. On the base it fails with "does not know how to round-trip server tool result". With this PR it compiles, and web_search still round-trips as server tool blocks. anthropic-messages.test.ts passes (76/76) and packages/ai type-checks. Turning unknown provider-executed results into text is consistent with what open-responses.ts already does.
Public API: unchanged.
One thing worth fixing, noted inline: results of type content are JSON-encoded whole, so file or image parts (for example a provider-executed read of an image) are sent to the model as raw base64 text.
Signed-off-by: Nicolas Languille <[email protected]>
Issue for this PR
Closes #53633
Type of change
What does this PR do?
When a conversation starts on
claude-code/*(tools run natively,providerExecuted: true) and is later continued on an Anthropic Messages route (e.g.google-vertex/claude-*), lowering the history threw:server_tool_use.namein the Anthropic SDK is a closed literal union covering onlyweb_search,code_execution, andweb_fetch, and tools likereadaren't in it. BothlowerServerToolResultand the assistanttool-callbranch inpackages/ai/src/protocols/anthropic-messages.tsthrew/produced an invalid block for anything outside that set.Fix: for a
providerExecutedtool-call or tool-result whose name isn't one of the three recognized server tools, emit a plaintextblock instead ofserver_tool_use/*_tool_result. Recognized server tools are untouched. Both the call and result sides had to change together — fixing only the result side would have left the call side emitting aserver_tool_useblock with anamethe SDK's type doesn't allow, trading one failure for a malformed request.Out of scope, left for follow-up: four additional Anthropic server tools (
bash_code_execution,text_editor_code_execution,tool_search_tool_regex,tool_search_tool_bm25) hit this same code path and are also unmapped. Adding them is a separate, unrelated change.How did you verify your code works?
Added a regression test reproducing the original failure (assistant message with a
readtool-call + result, bothproviderExecuted: true, lowered for an Anthropic Messages route) and confirmed it failed before the fix and passes after. Updated an existing test that had asserted the old throw-on-unknown-tool behavior, since that's exactly what this PR changes. Fullpackages/aitest file for this route:bun test test/provider/anthropic-messages.test.ts— 76/76 pass.Screenshots / recordings
N/A — no UI change.
Checklist