Fix tool_search bookkeeping when resuming from stateful marker#314217
Merged
Fix tool_search bookkeeping when resuming from stateful marker#314217
Conversation
Pre-scan the full message history before applying the previous_response_id slice, so tool_search_call ids and loaded tool names are remembered even when the assistant message that emitted the tool_search call carries the stateful marker (and is therefore dropped from the post-marker slice). Without this, the subsequent tool result was serialized as a plain function_call_output instead of tool_search_output, leaving deferred MCP tool definitions unloaded on the server and the model unable to invoke them. Fixes #313899
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes a Responses API resume bug where tool_search bookkeeping was lost when the assistant message containing the stateful marker (and its tool_search_call) was sliced out, causing subsequent tool results to be serialized incorrectly and deferred MCP tools to remain unloaded server-side.
Changes:
- Pre-scans the full raw message history to collect
tool_searchcall IDs and loaded deferred tool names before applying stateful-marker/compaction slicing. - Adds a regression test covering the “marker drops tool_search_call from post-marker slice” scenario (issue #313899).
Show a summary per file
| File | Description |
|---|---|
| extensions/copilot/src/platform/endpoint/node/responsesApi.ts | Pre-scan full message history to preserve tool_search bookkeeping across stateful-marker resume slicing. |
| extensions/copilot/src/platform/endpoint/node/test/responsesApiToolSearch.spec.ts | Adds a regression test ensuring tool_search_output serialization and MCP tool namespacing still work when the marker slices out the tool_search_call. |
Copilot's findings
- Files reviewed: 2/2 changed files
- Comments generated: 1
Contributor
|
This PR will be automatically cherry-picked to |
aeschli
approved these changes
May 4, 2026
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
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 #313899
When resuming from a Responses API
previous_response_id, the assistant message carrying the stateful marker (and thetool_search_callit emitted) was being sliced out of the input. Bookkeeping (toolSearchCallIds,toolSearchLoadedTools) was populated only while iterating that post-marker slice, so the subsequent tool result was incorrectly serialized asfunction_call_outputinstead oftool_search_output, leaving deferred MCP tool definitions unloaded on the server. The model would acknowledge the names returned bytool_searchbut couldn't actually invoke the tool.Pre-scan the full
messages[]for tool_search calls and their results before applying the slice.