.NET: [Bug]: ToolApprovalRequestContent triggers 2 times in handoff workflow with different Id's

[Mohanr1122]

Description

ToolApprovalRequestContent triggers 2 times in handoff workflow with different Id's
Using HandOffBuilder with triage agent and support agent, Approval requests triggering 2 times in RunStreamingAsync
one with normal request id and agentname:requestId.
I'm using workflow as Agent

Code Sample

Error Messages / Stack Traces

Package Versions

Microsoft.Agents.AI 1.19.0

.NET Version

.NET 10

Additional Context

No response

[github-actions]

🤖 Automated triage reproduction notes (agent-authored — trust but verify)

Agent analysis

Repro: dotnet/src/Microsoft.Agents.AI.Workflows/Specialized/AIAgentHostExecutor.cs::InvokeAgentAsync lines 226-295 emits an agent approval update and subsequently submits the same approval as an external request. It triggers when an approval-required tool is called inside a handoff workflow hosted with AsAIAgent and consumed through RunStreamingAsync. Minimal repro: build a triage-to-support handoff whose support agent calls an ApprovalRequiredAIFunction, host it as an agent, and collect streamed ToolApprovalRequestContent IDs.

• Failing test: dotnet/tests/Microsoft.Agents.AI.Workflows.UnitTests/HandoffOrchestrationTests.cs
• Files examined: dotnet/src/Microsoft.Agents.AI.Workflows/Specialized/AIAgentHostExecutor.cs, dotnet/src/Microsoft.Agents.AI.Workflows/Specialized/AIContentExternalHandler.cs, dotnet/src/Microsoft.Agents.AI.Workflows/Specialized/AIAgentUnservicedRequestsCollector.cs, dotnet/src/Microsoft.Agents.AI.Workflows/WorkflowSession.cs, dotnet/src/Microsoft.Agents.AI.Workflows/WorkflowHostAgent.cs, dotnet/tests/Microsoft.Agents.AI.Workflows.UnitTests/HandoffOrchestrationTests.cs
• Tests run: Handoffs_ToolApproval_AsAgentStreamingEmitsSingleRequestAsync (written, failed), Handoffs_TwoTransfers_SecondAgentUserApproval_ResponseServedByThirdAgentAsync (passed)
• Reported version: 1.19.0
• Current version: 1.19.0

[YashvantHange]

I would like to take this one.

The two requests come from two different emitters inside the same agent host executor, and both reach workflow.AsAIAgent().RunStreamingAsync.

HandoffAgentExecutor.InvokeAgentAsync streams the agent's updates straight out as workflow output (AddUpdateAsync -> context.YieldOutputAsync), so the ToolApprovalRequestContent the agent produced is emitted with the agent-local RequestId. Immediately after the stream ends, collector.SubmitAsync posts that same approval to the executor's request port, which raises a RequestInfoEvent. WorkflowSession turns that into a second ToolApprovalRequestContent, cloned with the workflow-facing request ID (CloneToolApprovalRequestContent(..., request.RequestId)), which is the <portId>:<requestId> shape reported here.

AIAgentHostExecutor.InvokeAgentAsync has the same pair of emissions, so a non-handoff agent host bound with EmitAgentUpdateEvents = true and InterceptUserInputRequests = false shows it too.

Only the second one is answerable: WorkflowSession matches an incoming ToolApprovalResponseContent by the workflow-facing ID in _pendingRequests. A response addressed with the agent-local ID misses that lookup and is forwarded into the workflow as an ordinary message, so it silently does nothing.

The existing coverage misses it because Test_AsAgent_ToolApprovalRequestContentPreservedInRequestInfoAsync filters updates on RawRepresentation is RequestInfoEvent, which selects the workflow-facing copy and never looks at the raw streamed one.

Planned fix, scoped and with no public API change: when a host executor raises an approval through its request port, it stops emitting that same ToolApprovalRequestContent as its own workflow output, so the workflow-facing request stays the single surfacing. AIContentExternalHandler already knows whether it is port-backed or intercepted, so intercepted user-input handling is left exactly as it is today. Function call content is untouched, since a function call in an agent stream is normally terminated inline in the same run and only the unterminated ones ever reach the port.

Regression tests on both paths: the handoff workflow hosted as an agent, and the plain AIAgentHostExecutor binding, each asserting a single approval request in the update stream carrying the ID the caller must answer with.

[anneheartrecord]

Repro aside, the two id shapes in the report (<requestId> vs agentname:<requestId>) suggest the same logical pending request is surfaced once per workflow scope transition, with each participant's emit path stamping its own id — so there is no stable cross-handoff request identity, and consumers keyed on the id see two distinct approvals for one decision.

Before working on it, two scope questions:

1. Is the intended contract "one ToolApprovalRequestContent per logical pending request, with an id that survives handoffs"? If so, the fix is probably normalizing the id at the emit path rather than deduplicating downstream.
2. This overlaps the approval-semantics work in .NET: Add pending tool approval closure semantics (#7872) #7909 (closure semantics) and .NET: expose pending tool approval requests from a restored AgentSession #7867 (pending approvals from restored sessions) — is the duplicate-emit behavior already tracked there, or is this a separate handoff-specific fix?

I can put up a two-agent handoff repro (triage → support, streaming asserted on RunStreamingAsync) plus the fix if the direction above is right.

[YashvantHange]

Both IDs come from one executor, not from one emit per handoff hop. HandoffAgentExecutor.InvokeAgentAsync streams the agent's updates out as workflow output, so the ToolApprovalRequestContent carries the agent-local RequestId; it then hands the same approval to its request port, and WorkflowSession clones it with the workflow-facing ID (<len>:<portId>:<requestId>, which reads as agentname:<requestId> in the report). A second transfer does not add a third copy. AIAgentHostExecutor has the same pair of emissions, so a plain agent binding with EmitAgentUpdateEvents = true and InterceptUserInputRequests = false shows it without any handoff.

On (1): the contract is one surfacing per pending request, and the ID that survives is already the workflow-facing one. It has to be, because it is the only answerable ID: WorkflowSession matches an incoming ToolApprovalResponseContent against _pendingRequests, keyed by the workflow-facing ID, and a response addressed with the agent-local ID misses that lookup and is forwarded into the workflow as an ordinary message, doing nothing. So this is neither downstream dedup nor renaming at the emit path; it is the executor not also emitting, as its own output, an approval it is about to raise on its port.

On (2): separate. #7909 is closure semantics for an approval once it exists and #7867 is surfacing pending approvals from a restored session; both assume a single well-formed request. This one is that request being surfaced twice.

#7945 is open for it and links this issue. It covers both executors and adds tests on the handoff path and the plain AIAgentHostExecutor binding, each asserting a single approval carrying the ID the caller must answer with. Review on it is welcome, in particular the question raised there: whether withholding the streamed copy and repairing it in SubmitAsync when no request was raised is the right split, or whether the executor should defer the whole approval-carrying update until the run ends.