fix: fire InputJsonEvent for server_tool_use blocks in streaming#1380
Open
atishay2 wants to merge 3 commits intoanthropics:mainfrom
Open
fix: fire InputJsonEvent for server_tool_use blocks in streaming#1380atishay2 wants to merge 3 commits intoanthropics:mainfrom
atishay2 wants to merge 3 commits intoanthropics:mainfrom
Conversation
added 3 commits
April 11, 2026 20:56
…silently The __stream__ methods in Stream and AsyncStream used separate if statements with no else clause, causing any unrecognized event type to be silently dropped. This broke client.beta.sessions.events.stream() entirely since managed agents emit different event names (agent.message, session.status_*) that don't match the hardcoded Messages API event list. Fix: Convert if/if/if/if to if/elif/elif/elif/else in both sync and async __stream__ methods so unknown events pass through process_data() instead of being silently discarded. Fixes anthropics#1357
ParsedContentBlock in types/parsed_message.py only included WebSearchToolResultBlock but was missing 5 other server tool result types: - CodeExecutionToolResultBlock - WebFetchToolResultBlock - BashCodeExecutionToolResultBlock - TextEditorCodeExecutionToolResultBlock - ToolSearchToolResultBlock When any of these arrived as content_block_start events during streaming, construct_type() failed discriminated union parsing and silently dropped them from current_snapshot.content. As a result, get_final_message().content was missing server tool results when client tools ran concurrently with server tools — the bug reported in anthropics#1325. Fix: add all 5 missing types to ParsedContentBlock to match ContentBlock. Adds sync + async regression tests with a fixture that streams both web_search_tool_result and code_execution_tool_result blocks alongside a concurrent client tool_use, asserting all 4 blocks are present in get_final_message().content. Fixes anthropics#1325
…ta handler build_events() only fired InputJsonEvent for tool_use blocks, skipping server_tool_use entirely. This is inconsistent with TRACKS_TOOL_INPUT which already includes ServerToolUseBlock — the SDK accumulates the input JSON internally for server tool use blocks but never surfaces the InputJsonEvent to the caller. Anyone streaming server tool calls and listening to on_input_json receives no events, even though the underlying JSON is being accumulated correctly.
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.
Summary
build_events()in_messages.pyonly firesInputJsonEventfortool_usecontent blocks, silently skippingserver_tool_useblocks even when the API streamsinput_json_deltaevents for them.Root Cause
There is an internal inconsistency in the same file:
TRACKS_TOOL_INPUT(line 427) correctly includes bothToolUseBlockandServerToolUseBlock, soaccumulate_event()properly accumulates the input JSON for both typesbuild_events()(line 363) only checkscontent_block.type == "tool_use", soInputJsonEventis never fired forserver_tool_useThe result: the streaming machinery accumulates the server tool input JSON internally but never surfaces it to the caller via the event stream.
Impact
Any code using
on_input_jsoncallbacks or iterating stream events to observe server tool input construction receives no events forserver_tool_useblocks. The silence gives no indication that anything is wrong — the input is being accumulated, just not emitted.Fix
Extend the type check to include
server_tool_use, consistent with howTRACKS_TOOL_INPUTalready handles both types.