Repository navigation
Foundry hosting: WorkflowAgent path drops cancellation_signal #7511
Description
Activity
🤖 Automated triage reproduction notes (agent-authored — trust but verify)
Agent analysis
Repro:
ResponsesHostServer._handle_responseinpython/packages/foundry_hosting/agent_framework_foundry_hosting/_responses.py(line 548) acceptscancellation_signal: asyncio.Eventbut drops it at lines 560–561 when dispatching to_handle_inner_workflow(line 739) and_handle_inner_agent(line 563), neither of which has acancellation_signalparameter. Minimal repro: runtest_cancellation_signal_forwarded.pywhich uses AST inspection to confirm the parameter is absent from both inner handler signatures and call sites. Fix requires addingcancellation_signalto both inner methods' signatures, forwarding it from_handle_response, and polling/honoring it aroundrun()calls and stream iterations in both handlers.- Failing test:
python/packages/foundry_hosting/tests/test_cancellation_signal_forwarded.py - Files examined: python/packages/foundry_hosting/agent_framework_foundry_hosting/_responses.py, python/packages/foundry_hosting/tests/test_responses.py, python/packages/foundry_hosting/pyproject.toml
- Tests run: python/packages/foundry_hosting/tests/test_cancellation_signal_forwarded.py
- Reported version:
1.0.0b260730 - Current version:
1.0.0b260730
- Failing test:
- linked a pull request that will close this issue.NET: Honor cancellation for Foundry-hosted workflow responses #7842
on Aug 24, 2026 The Python path is addressed through #7670
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Summary
In
agent-framework-foundry-hosting==1.0.0b260730(and currentmain),ResponsesHostServer._handle_responseacceptscancellation_signal: asyncio.Eventbut the WorkflowAgent branch calls_handle_inner_workflow(request, context)without forwarding the signal._handle_inner_workflowhas nocancellation_signalparameter and does not poll it aroundWorkflowAgent.run().Impact
POST /responses/{id}/cancel(viaazure-ai-agentserver-responses) sets the same event and stops event consumption (with winddown), so the response can becomecancelledwhile in-flight model/tool/workflow execution continues until natural completion. This wastes quota and risks late work after cancel for hosted WorkflowAgent products.Earlier design
Commit
ce8b630(Foundry hosted agent V2) previously passedcancellation_signalinto the workflow handler. The current Responses adapter appears to have dropped that wiring.Expected
cancellation_signalinto the WorkflowAgent (and preferably regular agent) inner handlers.run(), and stream iterations.run()awaits, and avoid emitting a successful terminal completion for abandoned work.Environment
agent-framework-foundry-hosting==1.0.0b260730azure-ai-agentserver-responses==1.0.0b9Tracked downstream as CFX-10485.