Python: [Bug]: AG-UI approval resume executes only the first of several approved calls in one batch — the rest are silently dropped

[antsok]

Description

Summary

When a model emits two or more approval_mode="always_require" calls in one assistant message, AG-UI correctly surfaces one interrupt per call, and a client that approves all of them gets exactly one executed. The others are dropped with no error, no event and no trace in the transcript: no TOOL_CALL_START, no result, and nothing in the final MESSAGES_SNAPSHOT.

The model therefore never learns the outcome of a call it made and the user approved, and a UI that renders tool calls from the event stream is left with a chip that never resolves.

A batch of one gated call plus never-require siblings works correctly — the siblings ride along in the pending entry's already_approved_requests and are released on the resume. It is specifically two or more gated calls that lose all but the first.

Reproduction

Self-contained, no network or credentials — a scripted chat client emitting a two-call batch, two always_require tools, and the stock AG-UI agent:

batch = [
    Content.from_function_call(call_id="c1", name="deploy_change", arguments={"target": "a"}),
    Content.from_function_call(call_id="c2", name="deploy_other", arguments={"target": "b"}),
]
# turn 1: run with a single user message -> RUN_FINISHED(outcome=interrupt, interrupts=[c1, c2])
# turn 2: resume with BOTH ids resolved/accepted
resume = [
    {"interruptId": "c1", "status": "resolved", "payload": {"accepted": True}},
    {"interruptId": "c2", "status": "resolved", "payload": {"accepted": True}},
]

Observed on the resume run, verbatim, against main @ d56e81357e5179b6f916b180c0cb34ea2e73c80b:

turn 1 -> interrupts surfaced: ['c1', 'c2']
turn 1 -> executed: []

resume -> executed:      ['deploy_change(a)']
resume -> results:       [('c1', 'deployed a')]
resume -> RUN_ERROR:     none
resume -> event types:   ['RunStartedEvent', 'ToolCallResultEvent', 'TextMessageStartEvent',
                          'TextMessageContentEvent', 'TextMessageEndEvent',
                          'MessagesSnapshotEvent', 'RunFinishedEvent']
resume -> snapshot roles: ['user', 'tool', 'assistant']

VERDICT: approved 2 call(s), executed 1

Expected: both tools execute, both results stream, and the snapshot carries two role="tool" messages.

The chat client's view of the resume turn confirms the loss is not a display artifact — it is handed user/text and a single tool/function_result for c1, with no approval response, no result and no function call for c2 anywhere in the transcript.

Where it is lost

Not in the AG-UI resume synthesis. Instrumenting _canonical_approval_resume_messages on the resume shows it doing exactly the right thing for both entries:

[synthesis] messages=2  handled=['c1', 'c2']  err=None

Both interrupt ids are validated, both approval responses are built, and no resume error is raised. Execution then produces one result. So the drop is downstream of the AG-UI layer, where the synthesized approval responses are turned into function invocations — the second response is present in the input and does not lead to a call.

That also explains the asymmetry with never-require siblings: those are carried inside the gated entry as already_approved_requests (_PendingApprovalWithSiblings) and are released as part of one approval, whereas two gated calls are two independent entries whose responses must each drive an execution.

Impact

An approved tool call that silently does not happen is worse than one that fails: nothing surfaces to the user, the model proceeds as though the call never existed, and any UI that pairs TOOL_CALL_START with a result shows an unresolvable pending state.

It also bites hardest exactly where batching is most natural — a plan that approves several writes at once, or a model that emits parallel calls for speed. In our own deployment the mitigation is an app-side shim that pops the parked approvals and executes them itself, which then has to re-stream and re-seat the results because the framework has no record of a call it never ran.

Prior art (checked before filing)

• Python: [Bug]: Mixed Tool Batch Applies Approval Wrapper To All Tool Calls #6385 (closed) — a mixed batch over-wrapping never-require siblings in approval requests at surfacing time; fixed by the per-item grouping this report references, and its scenario passes today. This report is the residual case: all-gated batches, where surfacing is correct but the resume executes only the first entry.
• Python: [Bug]: Approval-gated tool (confirm_changes flow) re-executes a second time on a later unrelated turn — duplicate side effect, not just a UI display issue #6851 — the confirm_changes flow re-executing a tool. Opposite symptom, and the legacy require_confirmation=True path; this report is the native-interrupt path with require_confirmation=False.
• Python: [Feature]: No way to serialize (or order) same-message function calls — stateful tools with write→read dependencies race #7386 — a feature request to order same-message function calls. Adjacent, but about sequencing calls that do run, not about one that never does.
• Python: Clear AG-UI queued approvals on cancel #6947 — clearing queued approvals on cancel. Different lifecycle point.
• Python: Improve function approval resume and replay #7345, Python: Prevent orphaned local approval responses #7462, Python: Fix AG-UI approval resume at the protocol boundary #7480 — all improved approval resume/replay and none change this: verified on 5f3ca8f9, which contains all three.
• Python: [Bug]: AG-UI approval resume is consumed (and the approved tool executed) before the run can fail — a post-consume failure makes the user's answer unrecoverable, and the retry is indistinguishable from a never-pending id #7458 — the same ingress path (_resolve_approval_responses), a different defect: there a resume is spent when the run fails after the consume, so the retry gets APPROVAL_RESUME_NOT_FOUND; here the resume run succeeds and simply executes only the first of several approved calls. Fixing either leaves the other intact — though the dropped second call does land in exactly the "consumed but never applied" state Python: [Bug]: AG-UI approval resume is consumed (and the approved tool executed) before the run can fail — a post-consume failure makes the user's answer unrecoverable, and the retry is indistinguishable from a never-pending id #7458 names as indistinguishable.

Affected packages: agent-framework-core (the function-invocation path that consumes synthesized approval responses). The AG-UI layer (agent-framework-ag-ui) appears to do its part correctly — see Where it is lost.

Verified against: live main @ d56e81357e5179b6f916b180c0cb34ea2e73c80b (2026-08-04T17:23Z, core 1.13.0) — installed fresh and reproduced with the stock agent_framework_ag_ui.AgentFrameworkAgent, no application wrappers of any kind. Also reproduces on 5f3ca8f9 and 07511b80.

Code Sample

Error Messages / Stack Traces

Package Versions

agent-framework-core: 1.13.0, agent-framework-ag-ui: 1.0.1

Python Version

No response

Additional Context

Suggested direction

The synthesized approval responses already carry everything needed — the AG-UI layer builds one per approved interrupt and reports both as handled. The gap is that only the first drives an invocation, so the natural fix is for the approval-response consumer to iterate every response present in the input rather than resolving a single pending approval per resume, and to release each one's call independently.

A regression test that approves two gated calls in one batch and asserts two executions and two results would pin it; the never-require sibling case should keep passing unchanged, since it already does.

[github-actions]

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

Agent analysis

Repro: AG-UI _resolve_approval_responses in python/packages/ag-ui/agent_framework_ag_ui/_agent_run.py (line ~1467) calls _filter_local_approval_responses_for_provider (line ~308) before _collect_approval_responses and _try_execute_function_call_groups; the occurrence-matching in _local_approval_content_ids_to_remove (line ~121) binds both approval responses to the same assistant-message tool-call occurrence and marks the second as a duplicate, so only the first reaches execution. Minimal repro: two approval_mode="always_require" FunctionTools, one assistant message with two tool_calls, two tool-role approval messages — assert two TOOL_CALL_RESULT events (see test_repro_7569_multi_gated_approval.py).

• Failing test: python/packages/ag-ui/tests/ag_ui/test_repro_7569_multi_gated_approval.py
• Files examined: python/packages/ag-ui/agent_framework_ag_ui/_agent_run.py, python/packages/core/agent_framework/_tools.py, python/packages/ag-ui/tests/ag_ui/test_approval_result_event.py, python/packages/ag-ui/tests/ag_ui/conftest.py, python/packages/core/tests/core/test_harness_tool_approval.py
• Tests run: python/packages/ag-ui/tests/ag_ui/test_repro_7569_multi_gated_approval.py::test_two_gated_approvals_both_execute
• Reported version: 1.13.0
• Current version: 1.13.0

[PeaceMaker-best]

I’d like to take this issue, subject to the core team’s confirmation required by python/AGENTS.md and the function-calling loop specification.

Proposed scope:

• Fix the AG-UI local-approval occurrence matching so two distinct approval responses from the same assistant batch are not collapsed onto the first tool-call occurrence.
• Preserve exactly-once behavior: every accepted local call executes once, rejected calls execute zero times, and hosted/deferred approval responses keep their existing provider/in-run paths.
• Keep the change internal to the existing approval-resolution path; no public API or protocol-shape changes.

I believe the affected scenario-matrix rows are Parallel calls, Mixed approved/rejected batch, AG-UI provider boundary, AG-UI approval result event, and AG-UI rejection/mixed decision.

Planned validation:

1. Add a base-failing AG-UI regression with two approval_mode="always_require" calls in one assistant response and two accepted resume entries.
2. Assert both tools execute exactly once, both terminal results are emitted, and the final snapshot contains both call/result pairs in model order.
3. Add a mixed accept/reject sibling case if the same occurrence matcher owns it.
4. Run the full AG-UI and core package tests plus package syntax and Pyright checks required by the specification.

Could the core team confirm that this ownership/scope and validation matrix are correct and assign the issue if appropriate? I will avoid opening a PR until that confirmation.

[PeaceMaker-best]

Read-only tracing against current main narrows the loss to an earlier stage than the automated triage note suggested:

1. agui_messages_to_agent_framework(...) correctly produces both distinct function_approval_response contents (c1 and c2).
2. _sanitize_tool_history(...) sees the first approval as a user message, removes only c1 from pending_tool_call_ids, then immediately treats the still-pending c2 as abandoned and injects a synthetic function_result ("Tool execution skipped - user provided follow-up message").
3. _deduplicate_messages(...) can then collapse the second ID-less approval message because its generic fallback hashes str(Content), which does not distinguish the nested approval identity here.
4. Calling _resolve_approval_responses(...) directly with the two pre-sanitization responses executes both calls and returns both results, so the occurrence matcher is not the failing stage for this reproduction.

I reproduced the reported end-to-end result locally with no network/model credentials (executed=['deploy_change(a)'], one TOOL_CALL_RESULT for c1), and the direct resolver control produced c1 and c2 exactly once.

I would therefore adjust the internal-only fix scope to make approval-control user messages consume their own call ids without marking unresolved siblings abandoned, and give ID-less approval controls a stable dedup identity that includes the approval/call occurrence. The planned end-to-end, mixed-decision, replay, hosted/deferred, and snapshot assertions remain the same. Still awaiting core-team confirmation before implementation/PR.