Add InvocationRequired property to FunctionCallContent

[Copilot]

Implementation Summary

Successfully implemented the InvocationRequired property for FunctionCallContent with all code review feedback addressed:

• Add InvocationRequired property to FunctionCallContent class

  • Property defaults to true (requires invocation)
  • Added to JSON file as "Stable"
  • Comprehensive XML documentation
  • Always serializes to JSON to enable proper roundtrip

• Update FunctionInvokingChatClient to set InvocationRequired = false when handling function

  • Set at beginning of ProcessFunctionCallAsync before any processing (only location)
  • Set for rejected function calls in approval flow
  • Handles ANY response including NotFound and rejected cases

• Update FunctionInvokingChatClient to filter out already-processed function calls

  • Modified CopyFunctionCalls to skip FunctionCallContent where InvocationRequired == false
  • Modified approval logic to skip FunctionCallContent where InvocationRequired == false
  • Prevents duplicate processing of function calls

• Comprehensive test coverage (1613 tests passing)

  • 7 tests in FunctionCallContentTests.cs (refactored as theories)
  • 5 tests in FunctionInvokingChatClientTests.cs for integration behavior
  • 1 test in FunctionInvokingChatClientApprovalsTests.cs for approval flow
  • Tests use ternary operator with ToChatResponseAsync() for cleaner code
  • Tests validate InvocationRequired=false passes through unprocessed
  • Tests validate approval flow respects InvocationRequired flag
  • Tests validate multiple FunctionInvokingChatClients in pipeline only process each function once
  • Tests validate JSON roundtrip for both true and false values

• Test refactoring per code review

  • Removed redundant tests
  • Consolidated tests into theories with streaming parameter
  • Replaced state reset with content cloning approach
  • Added InvocationRequired assertion to Constructor_PropsDefault
  • Refactored to use ternary with ToChatResponseAsync() to reduce duplication

• All code review feedback addressed

Original prompt

Add a get/set InvocationRequired property to FunctionCallContent. It should default to true and then be set to false by FunctionInvokingChatClient when the associated AIFunction has been processed and a FunctionResultContent created. It should be ignored by JSON serialization when it has its default value of false. Please ensure great test coverage in existing tests, validating the property is set appropriately, and add new tests to ensure that FunctionCallContent will InvocationRequired=false are ignored by FunctionInvokingChatClient; it shouldn't see them as content to be processed.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

Microsoft Reviewers: Open in CodeFlow

[stephentoub]

@copilot, fix the CI failures

[Copilot]

@copilot, fix the CI failures

Fixed in da8a275. The tests were reusing FunctionCallContent objects across multiple test iterations. When we set InvocationRequired=false during processing, subsequent iterations saw them as already processed. Added a ResetPlanFunctionCallStates helper method that resets InvocationRequired=true at the beginning of test helper methods. All 385 AI tests and 1115 abstraction tests now pass.

[stephentoub]

@javiercn, @jozkee, @westey-m, thoughts on this approach?

The goal here is to:

• Enable an IChatClient to produce FunctionCallContent / FunctionResultContent that should not be re-invoked by callers.
• Allow callers to distinguish whether an FCC is informative or a request. Today when a consumer gets back an FCC they don't know if it's been handled, and need to look for a corresponding FRC to determine whether it should be handled or not.
• Allow multiple FunctionInvocationChatClients to be in a pipeline and not duplicate work.
• Maybe allow FunctionCallContent / FunctionResultContent (or derivations to represent server-side invocations).

[Copilot]

Pull request overview

This PR adds an InvocationRequired property to FunctionCallContent to prevent duplicate processing of function calls in the FunctionInvokingChatClient. The property defaults to true and is set to false after a function call has been processed, allowing the middleware to distinguish between new function calls and already-processed ones. This is particularly useful in scenarios where chat history containing function calls is reused across multiple requests.

Key changes:

• Added InvocationRequired boolean property to FunctionCallContent with JSON serialization support (omitted when false)
• Modified FunctionInvokingChatClient to set the property to false after processing and filter out function calls with InvocationRequired = false
• Added comprehensive test coverage including unit tests for serialization behavior and integration tests for filtering logic

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
src/Libraries/Microsoft.Extensions.AI.Abstractions/Contents/FunctionCallContent.cs	Adds InvocationRequired property with field initializer defaulting to true, marked as experimental, with JsonIgnoreCondition.WhenWritingDefault to omit when false
src/Libraries/Microsoft.Extensions.AI/ChatCompletion/FunctionInvokingChatClient.cs	Updates CopyFunctionCalls to filter out function calls where InvocationRequired = false and sets the property to false in ProcessFunctionCallAsync and CreateFunctionResultContent
test/Libraries/Microsoft.Extensions.AI.Abstractions.Tests/Contents/FunctionCallContentTests.cs	Adds 6 unit tests covering property defaults, getters/setters, and JSON serialization/deserialization behavior
test/Libraries/Microsoft.Extensions.AI.Tests/ChatCompletion/FunctionInvokingChatClientTests.cs	Adds 4 integration tests for the filtering behavior and a ResetPlanFunctionCallStates helper method to reset the property when reusing test plans across multiple invocations

[Copilot]

Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• securitytools.pkgs.visualstudio.com
  • Triggering command: /opt/hostedtoolcache/CodeQL/2.23.7/x64/codeql/csharp/tools/linux64/Semmle.Autobuild.CSharp /opt/hostedtoolcache/CodeQL/2.23.7/x64/codeql/csharp/tools/linux64/Semmle.Autobuild.CSharp (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[rogerbarreto]

Assuming we will always have a FRC for invoked FCC even for server-side invoked FCCs.

The representation of a function that was already invoked already exists as the FRC, I understand the need for it but I'm not sure if this should be represented as an extra serializeable boolean in the FCC with not specific pointer/hint.

I suggest that we might just have a nullable [JsonIgnore] Result property pointing to what is the FRC for that FCC when it was already invoked.

Further downstream FICC could check if the FCC has a FRC as to know if it was invoked, this makes some API usage more intuitive as well.

Often I found myself having to store the FCC.Id to map what was the FRC.CallId, this would make some calling code easier to handle.

[javiercn]

@javiercn, @jozkee, @westey-m, thoughts on this approach?

The goal here is to:

• Enable an IChatClient to produce FunctionCallContent / FunctionResultContent that should not be re-invoked by callers.
• Allow callers to distinguish whether an FCC is informative or a request. Today when a consumer gets back an FCC they don't know if it's been handled, and need to look for a corresponding FRC to determine whether it should be handled or not.
• Allow multiple FunctionInvocationChatClients to be in a pipeline and not duplicate work.
• Maybe allow FunctionCallContent / FunctionResultContent (or derivations to represent server-side invocations).

Could we instead look for the matching FunctionResultContent on the stream? If we see a function -> result pair on the response we can consider it as handled, couldn't we?

I think this goes in line with what @rogerbarreto has in mind.

[jozkee]

@copilot address feedback and resolve conflicts with main.

[Copilot]

@copilot address feedback and resolve conflicts with main.

Addressed all test refactoring feedback in 8fa1a6b:

• Removed redundant tests and consolidated into theories
• Replaced ResetPlanFunctionCallStates with CloneContents approach
• All 400 AI tests + 1118 abstraction tests passing

Note: I haven't resolved merge conflicts with main yet as there are conflicts in test files. I'll need assistance resolving those since I cannot use git commit/push directly.