Skip to content

Foundry hosting: WorkflowAgent path drops cancellation_signal #7511

Description

Summary

In agent-framework-foundry-hosting==1.0.0b260730 (and current main), ResponsesHostServer._handle_response accepts cancellation_signal: asyncio.Event but the WorkflowAgent branch calls _handle_inner_workflow(request, context) without forwarding the signal. _handle_inner_workflow has no cancellation_signal parameter and does not poll it around WorkflowAgent.run().

Impact

POST /responses/{id}/cancel (via azure-ai-agentserver-responses) sets the same event and stops event consumption (with winddown), so the response can become cancelled while 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 passed cancellation_signal into the workflow handler. The current Responses adapter appears to have dropped that wiring.

Expected

  1. Forward cancellation_signal into the WorkflowAgent (and preferably regular agent) inner handlers.
  2. Poll / honor the signal between restore, run(), and stream iterations.
  3. On cancel: stop scheduling new work, cancel in-flight run() awaits, and avoid emitting a successful terminal completion for abandoned work.

Environment

  • Package: agent-framework-foundry-hosting==1.0.0b260730
  • Related: azure-ai-agentserver-responses==1.0.0b9

Tracked downstream as CFX-10485.

Metadata

Metadata

Labels

reproducedUsage: [Issues], Target: all issues that can be reproduced by the triage workflowworkflowsUsage: [Issues, PRs], Target: Workflows

Type

Projects

Status
Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions