Fix tool_search bookkeeping when resuming from stateful marker (#314217)

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

Author: bhavyaus

extensions/copilot/src/platform/endpoint/node/responsesApi.ts

@@ -330,6 +330,32 @@ function rawMessagesToResponseAPI(modelId: string, messages: readonly Raw.ChatMe
 		markerIndex = undefined;
 	}
 
+	const toolSearchCallIds = new Set<string>();
+	const toolSearchLoadedTools = new Set<string>();
+	// Only pre-scan when history will be sliced (matches the slicing block below);
+	// otherwise the serialization loop visits each tool_search_call before its
+	// result and populates these sets in order on its own.
+	const willSliceHistory = markerIndex !== undefined || latestCompactionMessageIndex !== undefined;
+	if (willSliceHistory) {
+		for (const message of messages) {
+			if (message.role === Raw.ChatRole.Assistant && message.toolCalls) {
+				for (const toolCall of message.toolCalls) {
+					if (toolCall.function.name === CUSTOM_TOOL_SEARCH_NAME) {
+						toolSearchCallIds.add(toolCall.id);
+					}
+				}
+			} else if (message.role === Raw.ChatRole.Tool && message.toolCallId && toolSearchCallIds.has(message.toolCallId) && toolsMap) {
+				const resultText = message.content
+					.filter(c => c.type === Raw.ChatCompletionContentPartKind.Text)
+					.map(c => c.text)
+					.join('');
+				for (const t of buildToolSearchOutputTools(resultText, toolsMap, shouldLoadToolFromToolSearch)) {
+					toolSearchLoadedTools.add(t.name);
+				}
+			}
+		}
+	}
+
 	if (markerIndex !== undefined) {
 		// Requests that resume from previous_response_id send only post-marker history,
 		// but they still need the latest compaction item even when that item predates
@@ -346,11 +372,6 @@ function rawMessagesToResponseAPI(modelId: string, messages: readonly Raw.ChatMe
 		messages = messages.slice(latestCompactionMessageIndex);
 	}
 
-	// Track which call_ids are tool_search_calls (from client-executed tool search)
-	const toolSearchCallIds = new Set<string>();
-	// Track tool names loaded via tool_search_output — these need a namespace field on function_call
-	const toolSearchLoadedTools = new Set<string>();
-
 	const input: OpenAI.Responses.ResponseInputItem[] = [];
 	for (const message of messages) {
 		switch (message.role) {

extensions/copilot/src/platform/endpoint/node/test/responsesApiToolSearch.spec.ts

@@ -379,6 +379,66 @@ describe('createResponsesRequestBody tools', () => {
 
 		expect(toolSearchOutput?.tools?.map(t => t.name)).toEqual([]);
 	});
+
+	it('still emits tool_search_output and namespaces deferred-tool calls when the stateful marker drops the tool_search_call from the post-marker slice (issue #313899)', () => {
+		// Repro for https://github.com/microsoft/vscode/issues/313899: when the Responses API
+		// resumes from a previous_response_id, the assistant message carrying the marker (and
+		// the tool_search_call it emitted) is sliced out of the input. Without scanning the
+		// full history first, the tool_search bookkeeping would be empty and the subsequent
+		// tool result would be incorrectly serialized as `function_call_output` instead of
+		// `tool_search_output`, leaving the deferred MCP tool definitions unloaded on the
+		// server and the model unable to invoke the tool it just discovered.
+		const modelId = 'gpt-5.4';
+		const statefulMarker = 'marker-abc';
+		const messages: Raw.ChatMessage[] = [
+			{ role: Raw.ChatRole.User, content: [{ type: Raw.ChatCompletionContentPartKind.Text, text: 'Use the MCP tool' }] },
+			{
+				role: Raw.ChatRole.Assistant,
+				// Marker lives on the same assistant turn that emitted the tool_search call.
+				content: [{
+					type: Raw.ChatCompletionContentPartKind.Opaque,
+					value: { type: 'stateful_marker', value: { modelId, marker: statefulMarker } },
+				}],
+				toolCalls: [{ id: 'call_ts_resume', type: 'function', function: { name: 'tool_search', arguments: '{"query":"mcp"}' } }],
+			},
+			{
+				role: Raw.ChatRole.Tool,
+				toolCallId: 'call_ts_resume',
+				content: [{ type: Raw.ChatCompletionContentPartKind.Text, text: '["some_mcp_tool"]' }],
+			},
+			{
+				role: Raw.ChatRole.Assistant,
+				content: [],
+				toolCalls: [{ id: 'call_mcp_resume', type: 'function', function: { name: 'some_mcp_tool', arguments: '{"input":"x"}' } }],
+			},
+		];
+
+		const body = createToolSearchScenario(messages);
+
+		const input = body.input as Array<{ type?: string; name?: string; namespace?: string; call_id?: string; tools?: Array<{ name: string }> }>;
+
+		expect({
+			previous_response_id: body.previous_response_id,
+			// The tool result must round-trip as a tool_search_output (not function_call_output)
+			toolSearchOutput: input.find(i => i.type === 'tool_search_output'),
+			// Any function_call_output for the tool_search call_id would be the bug
+			badFunctionCallOutput: input.find((i: any) => i.type === 'function_call_output' && i.call_id === 'call_ts_resume'),
+			// The follow-up MCP tool call must carry the namespace so the server can match
+			// it against the deferred tool loaded via tool_search_output.
+			mcpToolNamespace: input.find(i => i.type === 'function_call' && i.name === 'some_mcp_tool')?.namespace,
+		}).toEqual({
+			previous_response_id: statefulMarker,
+			toolSearchOutput: {
+				type: 'tool_search_output',
+				execution: 'client',
+				call_id: 'call_ts_resume',
+				status: 'completed',
+				tools: [expect.objectContaining({ name: 'some_mcp_tool', defer_loading: true })],
+			},
+			badFunctionCallOutput: undefined,
+			mcpToolNamespace: 'some_mcp_tool',
+		});
+	});
 });
 
 describe('OpenAIResponsesProcessor tool search events', () => {