Skip to content

fix: fire BetaInputJsonEvent for server_tool_use blocks during streaming#1442

Open
Zelys-DFKH wants to merge 2 commits intoanthropics:mainfrom
Zelys-DFKH:fix/fire-betainputjsonevent-for-server-tools
Open

fix: fire BetaInputJsonEvent for server_tool_use blocks during streaming#1442
Zelys-DFKH wants to merge 2 commits intoanthropics:mainfrom
Zelys-DFKH:fix/fire-betainputjsonevent-for-server-tools

Conversation

@Zelys-DFKH
Copy link
Copy Markdown

Issue

The input_json_delta event handler in lib/streaming/_beta_messages.py fires BetaInputJsonEvent for tool_use and mcp_tool_use blocks but not for server_tool_use, even though the API streams input_json_delta events for server tools the same way.

This is inconsistent with the TRACKS_TOOL_INPUT tuple, which already includes BetaServerToolUseBlock — so the SDK correctly accumulates the streamed input into content_block.input, but never fires the parsed event to consumers.

Solution

Include server_tool_use in the content-block type check on line 368:

if content_block.type in ("tool_use", "mcp_tool_use", "server_tool_use"):

Testing

All 16 beta messages streaming tests pass.

…de_execution continuation

This ensures streaming mode behaves consistently with non-streaming messages.create()
when the model uses code_execution tools that require container_id on subsequent turns.
The input_json_delta event handler was checking for tool_use and mcp_tool_use
but not server_tool_use, even though TRACKS_TOOL_INPUT already includes
BetaServerToolUseBlock. This prevented consumers from observing server tool
input (e.g. tool_search, web_search) as it streamed in.

Include server_tool_use in the content-block type check to make event firing
consistent with accumulation.
@Zelys-DFKH Zelys-DFKH requested a review from a team as a code owner April 24, 2026 17:33
@Zelys-DFKH
Copy link
Copy Markdown
Author

Note: PR #1380 addresses the same issue in the non-beta layer (InputJsonEvent in _messages.py). This PR covers the beta layer (BetaInputJsonEvent in _beta_messages.py) plus a separate fix for container propagation. The two PRs operate on different code paths and don't conflict, but maintainers may want to review them together to ensure consistency across both APIs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant