.NET: [Bug]: Checkpoint round-trip loses ToolApprovalRequestContent.ToolCall concrete type (FunctionCallContent → base ToolCallContent), breaking FICC approval resume #5350

Description

Summary

When a ToolApprovalRequestContent is persisted via CheckpointManager.CreateJson(...) (a JsonCheckpointStore-based store) during a HITL workflow and then restored on resume, ToolApprovalRequestContent.ToolCall appears to lose its concrete FunctionCallContent type and come back as something that no longer satisfies is FunctionCallContent in FunctionInvokingChatClient.ExtractAndRemoveApprovalRequestsAndResponses.

Because that method matches with

case ToolApprovalRequestContent tarc
    when tarc.ToolCall is FunctionCallContent { InformationalOnly: false }:

the TARC is silently skipped, the call id is never added to approvalRequestCallIds, and the downstream validation / invocation logic does not handle the approval as expected.

Environment

• Microsoft.Agents.AI / Microsoft.Agents.AI.Workflows 1.1 (.NET 10)
• Microsoft.Extensions.AI 10.5
• Storage: custom JsonCheckpointStore subclass persisting the JSON to SQL Server (Dapper). The CheckpointManager is created via CheckpointManager.CreateJson(store); no custom JsonSerializerOptions passed.
• Flow: workflow.AsAIAgent() is not used in the affected path; we drive the run directly with InProcessExecution.RunStreamingAsync(workflow, input, CheckpointManager, sessionId, ct) and resume with InProcessExecution.ResumeStreamingAsync(...).
• HITL mechanism: ApprovalRequiredAIFunction-wrapped tools inside a ChatClientAgent node that is bound into the workflow (pattern "B" in the published GroupChatToolApproval sample).

Expected behavior

After a checkpoint → resume cycle, ToolApprovalRequestContent.ToolCall restored through JsonCheckpointStore should remain an instance of the original concrete ToolCallContent subclass (FunctionCallContent), so that FunctionInvokingChatClient’s pattern matching continues to work unchanged.

Actual behavior

After resume, the ToolCall instance returned by request.TryGetDataAs<ToolApprovalRequestContent>() no longer matches is FunctionCallContent. As a result the approval pair is not extracted by FICC and the run either:

• raises InvalidOperationException: ToolApprovalRequestContent found with FunctionCall.CallId(s) '…' that have no matching ToolApprovalResponseContent. (if only the TARC side degrades), or
• passes the approval through unprocessed and causes OpenAI Responses to reject with No tool output found for function call call_… in the subsequent turn.

Reproduction outline

1. Build a workflow where a ChatClientAgent node is bound into WorkflowBuilder and uses an ApprovalRequiredAIFunction tool.
2. Run the workflow with durable checkpointing:

   var checkpointManager = CheckpointManager.CreateJson(myJsonCheckpointStore);
   await foreach (var evt in InProcessExecution.RunStreamingAsync(
       workflow, input, checkpointManager, sessionId, ct).WatchStreamAsync(ct))
   { ... }

3. On RequestInfoEvent, persist the envelope, terminate the run.
4. Later, resume:

   var run = await InProcessExecution.ResumeStreamingAsync(
       workflow, checkpointManager, sessionId, ct);
   var request = /* the resumed RequestInfoEvent.Request */;
   var tarc = request.TryGetDataAs<ToolApprovalRequestContent>();
   Console.WriteLine(tarc!.ToolCall?.GetType().FullName);
   // Observed: NOT FunctionCallContent

5. Build a ToolApprovalResponseContent with the restored tarc.ToolCall verbatim and send it back via run.SendResponseAsync(request.CreateResponse(taResp)).
6. FICC’s ExtractAndRemoveApprovalRequestsAndResponses fails to pick up the pair.

(I can produce a minimal standalone repro against a fake IChatClient if useful — let me know.)

Likely root cause (hypothesis)

ToolApprovalRequestContent.ToolCall is declared as the abstract base ToolCallContent. System.Text.Json requires polymorphic metadata ([JsonPolymorphic] + [JsonDerivedType] or equivalent TypeInfoResolver) to round-trip an abstract property through its concrete subtype. Unless JsonCheckpointStore is configured with AIJsonUtilities.DefaultOptions (or an equivalent resolver that knows about FunctionCallContent), ToolCall serializes as the base shape and deserializes back as the base type.

Two things to confirm in the repo:

1. Whether AIContent / ToolCallContent / FunctionCallContent currently carry [JsonPolymorphic] + [JsonDerivedType(typeof(FunctionCallContent), "...")] — or are only known to the resolver bundled in AIJsonUtilities.DefaultOptions.
2. What JsonSerializerOptions the default CheckpointManager.CreateJson(...) uses. If it does not pull from AIJsonUtilities.DefaultOptions by default, the polymorphic information for AIContent-derived members is effectively lost for any custom store.

Workaround currently in use

In our resume handler we reconstruct the concrete type before building the response:

var toolCall = tarc.ToolCall is FunctionCallContent fcc
    ? fcc
    : new FunctionCallContent(tarc.ToolCall!.CallId, /*name*/..., /*args*/...);
var response = new ToolApprovalResponseContent(tarc.RequestId, approved, toolCall);

This is fragile (we must know the original Name / Arguments to rebuild the FCC) and only masks the serializer-level problem.

Asks

1. Is this a known limitation of the JSON checkpoint path for AIContent-valued properties whose declared type is abstract? If so, documenting it would help.
2. Can CheckpointManager.CreateJson(...) default to (or transparently compose with) AIJsonUtilities.DefaultOptions so that AIContent polymorphism is preserved out of the box for JsonCheckpointStore implementations?
3. Alternatively, can ToolCallContent / AIContent be annotated with [JsonPolymorphic] + [JsonDerivedType(...)] so the polymorphism travels with the type itself regardless of the resolver?
4. If the official guidance is "you must pass your own JsonSerializerOptions", please document that explicitly next to CheckpointManager.CreateJson and the HITL samples. The current GroupChatToolApproval sample works because it does not checkpoint across process boundaries; the failure only appears under durable resume.

Code Sample

Error Messages / Stack Traces

Package Versions

Microsoft.Agents.AI 1.1.0, Microsoft.Agents.AI.Workflows 1.1.0

.NET Version

.NET 10

Additional Context

No response