[Eduard van Valkenburg (eavanvalkenburg)]

Motivation & Context

Restoring a parent checkpoint while answering multiple sibling requests from a propagated sub-workflow could re-register one request that was already being answered. Later checkpoints then retained that stale request, leaving an otherwise completed workflow idle with pending work. This restores checkpoint-resume behavior to match in-place resumes.

Description & Review Guide

• What are the major changes? Snapshot the child workflow's pending request IDs before forwarding a response, suppress only re-emitted events for those existing IDs, and add a fan-out/fan-in checkpoint regression.
• What is the impact of these changes? Already-propagated requests are not registered twice after restore, while newly-created requests, outputs, and checkpoint state continue unchanged.
• What do you want reviewers to focus on? The filtering boundary in WorkflowExecutor._handle_response and the restored multi-request regression.

Related Issue

Closes #9270

AI Assistance

• No material AI assistance was used.
• This is an AI-assisted contribution. I reviewed, understood, and verified all submitted content and accept responsibility for it.

AI assistance details: implementation, regression test, validation, and PR description.

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR links to an agreed issue with no competing open PR, or the Related Issue section documents a trivial-change or repository-automation exception.
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.

[Copilot]

🟡 Changes recommended

ID-based filtering can incorrectly discard a valid re-prompt that reuses its request ID.

1 open finding

• Avoid filtering new events that reuse consumed request IDs · New

What changed in this PR

Fixes stale sibling requests when restoring checkpointed Python sub-workflows.

Changes:

• Filters previously propagated requests during response handling.
• Adds a fan-out/fan-in checkpoint restoration regression test.

File	Description
_workflow_executor.py	Filters restored pending request events.
test_sub_workflow.py	Tests restored sibling-request completion.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

MAF Automated Review — Iteration 1

Result: Findings reported
Scope: full PR (1 commit(s)): 9dfd637226e5
Model: gpt-5.6-sol

Overview

The change snapshots child request IDs before resuming and filters restored sibling events before forwarding the result, with regression coverage for a checkpointed fan-out/fan-in flow. Existing response validation, child-owned pending state, and same-instance run serialization constrain the change well. However, ID-only filtering also removes a genuinely new sequential request when a response handler reuses the completed request's explicit ID, orphaning that continuation.

Reviewed the supplied pull-request change set across correctness, security/reliability, architecture, and failure behavior.
1 verified finding remained after source verification (1 medium) across 1 file. Details are attached to the affected lines below.

Affected areas: python/packages/core/agent_framework/_workflows/_workflow_executor.py

[Jose Alvarez (jpalvarezl)]

The restored cancellation fix now applies the same exact-event suppression as response handling. I verified both bulk sibling cancellation and a repeated partial restore/cancel chain clear the live pending map and persisted checkpoint without leaving the workflow idle with pending requests. The net-new diff and current feedback show no distinct regressions.