[WIP] Fix message ordering when processing function approval responses #7158

Copilot · 2025-12-16T15:19:23Z

Fix message ordering issue in FunctionInvokingChatClient

Problem Analysis

When FunctionInvokingChatClient processes FunctionApprovalResponseContent, it incorrectly reorders chat messages. User messages added after a function approval rejection are moved before the tool call/result instead of remaining at the end of the conversation.

Additionally, when there are multiple approval request/response pairs with messages interleaved between them, only the first approval request index was tracked, causing incorrect ordering for subsequent pairs.

Changes

Implementation Summary

Modified ExtractAndRemoveApprovalRequestsAndResponses to track and return a dictionary of insertion indices (one per call ID) where approval requests were originally located
Updated ProcessFunctionApprovalResponses to process rejections individually in reverse index order, using InsertRange/Insert to maintain message ordering at each approval's original position
Adjusted all indices after message removal to account for removed messages before each tracked position
Extended method signatures to pass the dictionary of indices through the call chain
Fixed critical bug where rejectedInsertionIndex didn't account for whether FCC messages were actually inserted
Fixed bug where ANY FunctionResultContent (even unrelated ones) would cause append-at-end behavior
Now only appends at end when approval requests in the current batch have already been executed
Clarified example comments to show message state after extraction rather than before
Rejections now correctly preserve message ordering for multiple interleaved approval/rejection pairs

Current Status

✅ Rejections: Fully working - each rejection is processed at its original position, preserving interleaved user messages
✅ Single Approval Pair: Works correctly with existing tests
⏳ Multiple Approved Functions: Currently uses the first approval's index for all approved function results (needs further work)

Note: This is a work in progress. The fix for rejections is complete. The fix for approved functions with multiple interleaved pairs requires additional refactoring to process each approval individually and insert their results at the correct positions while handling asynchronous execution.

All 25 existing approval tests pass. The new test for multiple interleaved pairs demonstrates the remaining issue with approved functions. CodeQL security checks found no issues.

Original prompt

Problem

When FunctionInvokingChatClient processes FunctionApprovalResponseContent, it incorrectly reorders chat messages. User messages added after a function approval rejection are moved before the tool call/result instead of remaining at the end of the conversation.

This is reported in issue #7156: #7156

Root Cause

In FunctionInvokingChatClient.cs, the ProcessFunctionApprovalResponses method:

Calls ExtractAndRemoveApprovalRequestsAndResponses which removes FunctionApprovalRequestContent and FunctionApprovalResponseContent from their original positions in the message list

Then appends the reconstructed FunctionCallContent and FunctionResultContent messages at the end of the list using AddRange and Add (lines 1276-1287)

This destroys the relative ordering with any messages that came after the approval response.

Expected message order:
user: 1st message
assistant: tool_call
tool_call: reject
user: 2nd message  ← Should come last
Actual message order:
user: 1st message
user: 2nd message  ← Incorrectly positioned before tool call
assistant: tool_call
tool_call: reject
Required Fix

The ExtractAndRemoveApprovalRequestsAndResponses method needs to track the original index/position of the approval request messages. Then ProcessFunctionApprovalResponses should:

Insert the reconstructed FunctionCallContent message at the original position of the approval request (not at the end)

Insert the rejection FunctionResultContent immediately after

Ensure any user messages that came after the approval response remain at the end

The key change is in ProcessFunctionApprovalResponses - instead of:
originalMessages.AddRange(preDownstreamCallHistory);
// ...
originalMessages.Add(rejectedPreDownstreamCallResultsMessage);
It should insert at the correct position to preserve message ordering relative to any subsequent user messages.

Files to Modify

src/Libraries/Microsoft.Extensions.AI/ChatCompletion/FunctionInvokingChatClient.cs

Testing

The fix should be validated with test cases covering:

Rejection with a user message added after the approval response

Approval with a user message added after the approval response

Multiple approval/rejection scenarios with interleaved user messages

Existing tests in test/Libraries/Microsoft.Extensions.AI.Tests/ChatCompletion/FunctionInvokingChatClientApprovalsTests.cs should continue to pass, and new tests should be added for the scenarios described in issue #7156.

This pull request was created as a result of the following prompt from Copilot chat.

Problem

When FunctionInvokingChatClient processes FunctionApprovalResponseContent, it incorrectly reorders chat messages. User messages added after a function approval rejection are moved before the tool call/result instead of remaining at the end of the conversation.

This is reported in issue #7156: #7156

Root Cause

In FunctionInvokingChatClient.cs, the ProcessFunctionApprovalResponses method:

Calls ExtractAndRemoveApprovalRequestsAndResponses which removes FunctionApprovalRequestContent and FunctionApprovalResponseContent from their original positions in the message list

Then appends the reconstructed FunctionCallContent and FunctionResultContent messages at the end of the list using AddRange and Add (lines 1276-1287)

This destroys the relative ordering with any messages that came after the approval response.

Expected message order:
user: 1st message
assistant: tool_call
tool_call: reject
user: 2nd message  ← Should come last
Actual message order:
user: 1st message
user: 2nd message  ← Incorrectly positioned before tool call
assistant: tool_call
tool_call: reject
Required Fix

The ExtractAndRemoveApprovalRequestsAndResponses method needs to track the original index/position of the approval request messages. Then ProcessFunctionApprovalResponses should:

Insert the reconstructed FunctionCallContent message at the original position of the approval request (not at the end)

Insert the rejection FunctionResultContent immediately after

Ensure any user messages that came after the approval response remain at the end

The key change is in ProcessFunctionApprovalResponses - instead of:
originalMessages.AddRange(preDownstreamCallHistory);
// ...
originalMessages.Add(rejectedPreDownstreamCallResultsMessage);
It should insert at the correct position to preserve message ordering relative to any subsequent user messages.

Files to Modify

src/Libraries/Microsoft.Extensions.AI/ChatCompletion/FunctionInvokingChatClient.cs

Testing

The fix should be validated with test cases covering:

Rejection with a user message added after the approval response

Approval with a user message added after the approval response

Multiple approval/rejection scenarios with interleaved user messages

Existing tests in test/Libraries/Microsoft.Extensions.AI.Tests/ChatCompletion/FunctionInvokingChatClientApprovalsTests.cs should continue to pass, and new tests should be added for the scenarios described in issue #7156.

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

Microsoft Reviewers: Open in CodeFlow

…cessing - Track insertion index for approval request messages before removal - Insert reconstructed FunctionCallContent and FunctionResultContent at correct position - Pass insertion index through to ProcessFunctionCallsAsync for approved functions - Handle edge case where already-executed approvals exist - Add tests for rejection and approval scenarios with user messages after responses Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Copilot

Pull request overview

This PR fixes a message ordering bug in FunctionInvokingChatClient where user messages added after function approval responses were incorrectly repositioned before tool call/result messages instead of remaining at the end of the conversation.

Key changes:

Modified ExtractAndRemoveApprovalRequestsAndResponses to track and return the original index position of approval requests
Updated ProcessFunctionApprovalResponses to insert reconstructed function call and result messages at their original positions using InsertRange/Insert instead of appending with AddRange/Add
Extended ProcessFunctionCallsAsync to accept an insertionIndex parameter for placing approved function results at the correct position

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
FunctionInvokingChatClient.cs	Core fix: tracks approval request positions and uses insertion instead of appending to preserve message ordering
FunctionInvokingChatClientApprovalsTests.cs	Adds test coverage for rejection and approval scenarios with user messages following approval responses

src/Libraries/Microsoft.Extensions.AI/ChatCompletion/FunctionInvokingChatClient.cs

…nvokingChatClient.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

Copilot · 2025-12-17T02:52:57Z

src/Libraries/Microsoft.Extensions.AI/ChatCompletion/FunctionInvokingChatClient.cs

+        //   Before:
+        //     [User, FunctionApprovalRequest(A), FunctionApprovalResponse(A), FunctionResult(A), FunctionApprovalRequest(B)]
+        //   After processing approval for B, if we inserted at the original index of B, we'd get:
+        //     [User, FunctionApprovalRequest(A), FunctionApprovalResponse(A), FunctionResult(A), FunctionCall(B), FunctionResult(B)]
+        //   But if there are already function results present (e.g., for A), we want to append new function calls/results for B at the end:
+        //     [User, FunctionApprovalRequest(A), FunctionApprovalResponse(A), FunctionResult(A), FunctionApprovalRequest(B), FunctionCall(B), FunctionResult(B)]
+        //   This preserves the correct chronological order of function calls and results.


The example comment is confusing because it shows FunctionApprovalRequest and FunctionApprovalResponse in the message list, but these would have been removed by the time this logic runs. Consider clarifying that the "Before" represents the original user input before extraction, or showing the actual state of the messages list at this point (after extraction but before insertion). For example: "Before extraction: [User, FAReq(A), FARes(A), FAReq(B)]; After extraction: [User, FRes(A)]; After insertion with functionResultCallIds present: [User, FRes(A), FCall(B), FRes(B)]"

Suggested change

// Before:

// [User, FunctionApprovalRequest(A), FunctionApprovalResponse(A), FunctionResult(A), FunctionApprovalRequest(B)]

// After processing approval for B, if we inserted at the original index of B, we'd get:

// [User, FunctionApprovalRequest(A), FunctionApprovalResponse(A), FunctionResult(A), FunctionCall(B), FunctionResult(B)]

// But if there are already function results present (e.g., for A), we want to append new function calls/results for B at the end:

// [User, FunctionApprovalRequest(A), FunctionApprovalResponse(A), FunctionResult(A), FunctionApprovalRequest(B), FunctionCall(B), FunctionResult(B)]

// This preserves the correct chronological order of function calls and results.

// Before extraction (original user input and approval messages):

// [User, FunctionApprovalRequest(A), FunctionApprovalResponse(A), FunctionResult(A), FunctionApprovalRequest(B)]

// After extraction of approval requests/responses (state of 'messages' at this point, with existing results only):

// [User, FunctionResult(A)]

// After processing approval for B, if we inserted at the original index of B, we'd conceptually place the new call/result

// where B's approval request was, interleaving them with existing messages:

// [User, FunctionResult(A), FunctionCall(B), FunctionResult(B)]

// But if there are already function results present (e.g., for A), we instead append new function calls/results for B at the end

// of the current list of messages to preserve chronological ordering relative to any prior calls/results.

Updated in commit e58a3ae. The example now shows the state after extraction (e.g., [User, FunctionResult(A)]) rather than before, making it clearer what the actual message list contains when this logic runs.

Copilot · 2025-12-17T02:52:57Z

src/Libraries/Microsoft.Extensions.AI/ChatCompletion/FunctionInvokingChatClient.cs

+
+            // Calculate the insertion position: right after the FCC messages we just inserted
+            int rejectedInsertionIndex = insertionIndex >= 0 && insertionIndex <= originalMessages.Count
+                ? insertionIndex + (allPreDownstreamCallMessages?.Count ?? 0)


The calculation of rejectedInsertionIndex doesn't account for whether FCC messages were actually inserted into originalMessages. When hasConversationId is true, FCC messages are not inserted (line 1297-1308), but this calculation still adds allPreDownstreamCallMessages.Count to the index. This causes rejection messages to be inserted at the wrong position when there are messages after the approval response. The calculation should only add the FCC count when !hasConversationId. For example: insertionIndex + (!hasConversationId ? (allPreDownstreamCallMessages?.Count ?? 0) : 0)

Suggested change

? insertionIndex + (allPreDownstreamCallMessages?.Count ?? 0)

? insertionIndex + (!hasConversationId ? (allPreDownstreamCallMessages?.Count ?? 0) : 0)

Fixed in commit e58a3ae. The calculation now only adds the FCC count when !hasConversationId, ensuring rejection messages are inserted at the correct position.

stephentoub · 2026-01-06T16:35:30Z

cc: @westey-m

stephentoub · 2026-01-06T16:35:44Z

@copilot, please address any pending feedback

…Id and clarify example comment - Only add FCC count to rejectedInsertionIndex when messages were actually inserted (!hasConversationId) - Update example comment to show state after extraction rather than before, making it clearer what the actual message list contains at the point the logic runs Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

jozkee · 2026-01-09T18:55:01Z

src/Libraries/Microsoft.Extensions.AI/ChatCompletion/FunctionInvokingChatClient.cs

+        if (functionResultCallIds is { Count: > 0 } && insertionIndex >= 0)
+        {
+            insertionIndex = messages.Count;
        }


@copilot, since it fallbacks to append-at-end when there's a FunctionResultContent in the messages, we still have the bug in cases that have FRC prior to the approval request/response pairs.

Fixed in commit 1bf5d84. Now tracks whether any approval responses were skipped (already executed) and only appends at end for those cases, not for unrelated FunctionResultContent items.

jozkee · 2026-01-09T18:56:08Z

...ies/Microsoft.Extensions.AI.Tests/ChatCompletion/FunctionInvokingChatClientApprovalsTests.cs

+        [
+            new ChatMessage(ChatRole.User, "1st message"),
+            new ChatMessage(ChatRole.Assistant, [new FunctionCallContent("callId1", "Func1")]),
+            new ChatMessage(ChatRole.Tool, [new FunctionResultContent("callId1", result: "Error: Tool call invocation was rejected by user.")]),


@copilot the message was recently updated.

Suggested change

new ChatMessage(ChatRole.Tool, [new FunctionResultContent("callId1", result: "Error: Tool call invocation was rejected by user.")]),

new ChatMessage(ChatRole.Tool, [new FunctionResultContent("callId1", result: "Tool call invocation rejected.")]),

@jozkee

…e insertion - Track whether any approval responses were skipped due to already being executed - Only append at end when approval requests in current batch have already been executed - Fix test to use correct rejection message format - Addresses @jozkee feedback about FRC prior to approval request/response pairs Co-authored-by: jozkee <16040868+jozkee@users.noreply.github.com>

jozkee · 2026-01-10T01:17:35Z

@stephentoub, @westey-m, I think we need to fix this with a list of indexes, not just the first one it finds.

If the FICC receives multiple request/response pairs with messages interleaved, it will cause the same bug.

It is a theoretical case, because you will never have messages in between request/response pairs, it would need to be manually added to list of messages. It may be possible if someone is piling up approval requests in top of the FICC and sending them in batch.

[Fact]
public async Task MultipleApprovalRequestResponsePairsWithInterleavedUserMessagesPreservesOrderingAsync()
{
    // This test verifies that when there are multiple approval request/response pairs
    // in a single call with user messages interleaved between them, the message ordering
    // is preserved correctly. All approvals are processed in one invocation.
    var options = new ChatOptions
    {
        Tools =
        [
            new ApprovalRequiredAIFunction(AIFunctionFactory.Create(() => "Result 1", "Func1")),
            new ApprovalRequiredAIFunction(AIFunctionFactory.Create(() => "Result 2", "Func2")),
        ]
    };

    List<ChatMessage> input =
    [
        new ChatMessage(ChatRole.User, "1st user message"),
        new ChatMessage(ChatRole.Assistant,
        [
            new FunctionApprovalRequestContent("callId1", new FunctionCallContent("callId1", "Func1"))
        ]) { MessageId = "resp1" },
        new ChatMessage(ChatRole.User,
        [
            new FunctionApprovalResponseContent("callId1", true, new FunctionCallContent("callId1", "Func1"))
        ]),
        new ChatMessage(ChatRole.User, "2nd user message"),
        new ChatMessage(ChatRole.Assistant,
        [
            new FunctionApprovalRequestContent("callId2", new FunctionCallContent("callId2", "Func2"))
        ]) { MessageId = "resp2" },
        new ChatMessage(ChatRole.User,
        [
            new FunctionApprovalResponseContent("callId2", true, new FunctionCallContent("callId2", "Func2"))
        ]),
        new ChatMessage(ChatRole.User, "3rd user message"),
    ];

    // The expected input to downstream client should preserve all message ordering:
    // 1. User "1st user message" - should remain in place
    // 2. Assistant with FunctionCallContent(callId1) - recreated from approval
    // 3. Tool with FunctionResultContent(callId1) - from executing approved function
    // 4. User "2nd user message" - should remain in place
    // 5. Assistant with FunctionCallContent(callId2) - recreated from approval
    // 6. Tool with FunctionResultContent(callId2) - from executing approved function
    // 7. User "3rd user message" - should remain at the end
    List<ChatMessage> expectedDownstreamClientInput =
    [
        new ChatMessage(ChatRole.User, "1st user message"),
        new ChatMessage(ChatRole.Assistant, [new FunctionCallContent("callId1", "Func1")]),
        new ChatMessage(ChatRole.Tool, [new FunctionResultContent("callId1", result: "Result 1")]),
        new ChatMessage(ChatRole.User, "2nd user message"),
        new ChatMessage(ChatRole.Assistant, [new FunctionCallContent("callId2", "Func2")]),
        new ChatMessage(ChatRole.Tool, [new FunctionResultContent("callId2", result: "Result 2")]),
        new ChatMessage(ChatRole.User, "3rd user message"),
    ];

    List<ChatMessage> downstreamClientOutput =
    [
        new ChatMessage(ChatRole.Assistant, "Final response"),
    ];

    List<ChatMessage> output =
    [
        new ChatMessage(ChatRole.Assistant, [new FunctionCallContent("callId1", "Func1")]),
        new ChatMessage(ChatRole.Tool, [new FunctionResultContent("callId1", result: "Result 1")]),
        new ChatMessage(ChatRole.Assistant, [new FunctionCallContent("callId2", "Func2")]),
        new ChatMessage(ChatRole.Tool, [new FunctionResultContent("callId2", result: "Result 2")]),
        new ChatMessage(ChatRole.Assistant, "Final response"),
    ];

    await InvokeAndAssertAsync(options, input, downstreamClientOutput, output, expectedDownstreamClientInput);

    await InvokeAndAssertStreamingAsync(options, input, downstreamClientOutput, output, expectedDownstreamClientInput);
}

jozkee · 2026-01-12T18:17:37Z

@copilot, address this comment #7158 (comment).

Copilot · 2026-01-12T18:27:47Z

@copilot, address this comment #7158 (comment).

I've analyzed the issue and added the test case which confirms the bug exists. The current implementation tracks only the first approval request index, causing messages between multiple approval request/response pairs to be incorrectly ordered.

The fix requires tracking indices for each approval request by call ID and processing them individually. I've started the implementation but it requires significant refactoring of ProcessFunctionApprovalResponses and related methods to handle multiple insertion points.

Working on completing the fix - the key changes are:

Track original index for each approval request by call ID (done)
Process and insert each approval/rejection at its correct position in reverse order (in progress)
Handle approved function result insertion at corresponding positions (remaining)

Will have the complete fix ready shortly.

…ndividually - Modified ExtractAndRemoveApprovalRequestsAndResponses to track each approval request's original index by call ID - Refactored ProcessFunctionApprovalResponses to process rejections individually at their correct positions - Process rejections in reverse index order to avoid index shifting issues - Added test case for multiple interleaved approval/rejection pairs - Note: Approved functions still need individual processing (currently uses first index for all) Co-authored-by: jozkee <16040868+jozkee@users.noreply.github.com>

Initial plan

10ba264

Copilot AI assigned Copilot and stephentoub Dec 16, 2025

Copilot started work on behalf of stephentoub December 16, 2025 15:19 View session

Copilot AI and others added 2 commits December 16, 2025 15:49

Add clarifying comments for edge case handling in approval processing

ba5e9bf

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Copilot AI changed the title ~~[WIP] Fix message ordering in FunctionInvokingChatClient~~ Fix message ordering when processing function approval responses Dec 16, 2025

Copilot AI requested a review from stephentoub December 16, 2025 15:55

Copilot finished work on behalf of stephentoub December 16, 2025 15:55

stephentoub marked this pull request as ready for review December 16, 2025 15:56

stephentoub requested a review from a team as a code owner December 16, 2025 15:56

Copilot AI review requested due to automatic review settings December 16, 2025 15:56

Copilot AI reviewed Dec 16, 2025

View reviewed changes

Update src/Libraries/Microsoft.Extensions.AI/ChatCompletion/FunctionI…

e65dd44

…nvokingChatClient.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

stephentoub requested a review from Copilot December 17, 2025 02:42

Copilot started reviewing on behalf of stephentoub December 17, 2025 02:43 View session

stephentoub linked an issue Dec 17, 2025 that may be closed by this pull request

FunctionInvokingChatClient reorder messages when using FunctionApprovalResponseContent #7156

Open

Copilot AI reviewed Dec 17, 2025

View reviewed changes

stephentoub added the area-ai Microsoft.Extensions.AI libraries label Jan 5, 2026

Copilot started work on behalf of stephentoub January 6, 2026 16:36 View session

Copilot finished work on behalf of stephentoub January 6, 2026 16:46

Merge branch 'main' into copilot/fix-message-ordering-issue

e0bb70d

jozkee reviewed Jan 9, 2026

View reviewed changes

Copilot started work on behalf of jozkee January 9, 2026 18:55 View session

jozkee reviewed Jan 9, 2026

View reviewed changes

Copilot finished work on behalf of jozkee January 9, 2026 19:10

Copilot AI requested a review from jozkee January 9, 2026 19:10

Copilot started work on behalf of jozkee January 9, 2026 19:11 View session

Copilot finished work on behalf of jozkee January 9, 2026 19:12

Copilot started work on behalf of jozkee January 12, 2026 18:19 View session

Copilot AI changed the title ~~Fix message ordering when processing function approval responses~~ [WIP] Fix message ordering when processing function approval responses Jan 12, 2026

Copilot finished work on behalf of jozkee January 12, 2026 18:33

	? insertionIndex + (allPreDownstreamCallMessages?.Count ?? 0)
	? insertionIndex + (!hasConversationId ? (allPreDownstreamCallMessages?.Count ?? 0) : 0)

	new ChatMessage(ChatRole.Tool, [new FunctionResultContent("callId1", result: "Error: Tool call invocation was rejected by user.")]),
	new ChatMessage(ChatRole.Tool, [new FunctionResultContent("callId1", result: "Tool call invocation rejected.")]),

[WIP] Fix message ordering when processing function approval responses #7158

Are you sure you want to change the base?

[WIP] Fix message ordering when processing function approval responses #7158

Uh oh!

Conversation

Copilot AI commented Dec 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Fix message ordering issue in FunctionInvokingChatClient

Problem Analysis

Changes

Implementation Summary

Current Status

Problem

Root Cause

Expected message order:

Actual message order:

Required Fix

Files to Modify

Testing

Problem

Root Cause

Expected message order:

Actual message order:

Required Fix

Files to Modify

Testing

Microsoft Reviewers: Open in CodeFlow

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

stephentoub commented Jan 6, 2026

Uh oh!

stephentoub commented Jan 6, 2026

Uh oh!

jozkee Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

jozkee Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

jozkee commented Jan 10, 2026

Uh oh!

jozkee commented Jan 12, 2026

Uh oh!

Copilot AI commented Jan 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Copilot AI commented Dec 16, 2025 •

edited

Loading