Observed Behavior

A functional workflow runs two branches with asyncio.gather. The left branch awaits a step and then calls request_info("approve"); the right branch calls request_info("review"). Each pending request is answered once, and the run is resumed with exactly the responses to the requests it reported.

The first run pauses on review. The second run receives the response to review, but the left branch, whose step is now served from the cache, reaches request_info("approve") and pauses first. The step that asks review is entered after this pause and stops at entry, before it looks up its response. The response to review is never consumed, and the third run, which carries only the response to approve, asks review again.

A client that answers each request once therefore sees the same request twice.

Expected Behavior

A response supplied for a pending request is delivered to the step that asked it, as in 1.20.0 and 1.21.0: the second run consumes the response to review and pauses on approve, and the third run completes without asking review again.

Steps to Reproduce

1. Save the script below and run it with agent-framework-core 1.22.0. No model or checkpoint storage is needed.
2. The first run reports the pending request review; answer it.
3. The second run reports approve; answer it.
4. The third run reports review again.

Minimal Reproduction

import asyncio
import collections
from importlib.metadata import version

from agent_framework import RunContext, step, workflow


@step
async def fetch(name: str) -> int:
    await asyncio.sleep(0.01)  # e.g. a model or HTTP call
    return 1


@step
async def ask(name: str, ctx: RunContext) -> int:
    return await ctx.request_info(f"{name}?", int, request_id=name)


async def left() -> int:
    return await fetch("data") + await ask("approve")


async def right() -> int:
    return await ask("review")


@workflow
async def flow(x: int) -> int:
    a, b = await asyncio.gather(left(), right())
    return a + b


async def main():
    app = flow.build()
    result = await app.run(0)
    asked = collections.Counter()
    while pending := result.get_request_info_events():
        ids = [event.request_id for event in pending]
        print("asks:", ids)
        asked.update(ids)
        result = await app.run(responses={rid: 1 for rid in ids})
    print(f"agent-framework-core {version('agent-framework-core')}: outputs={result.get_outputs()}, asked={dict(asked)}")
    assert all(count == 1 for count in asked.values()), "an answered request was asked again"


asyncio.run(main())

Error Messages and Stack Traces

asks: ['review']
asks: ['approve']
asks: ['review']
agent-framework-core 1.22.0: outputs=[3], asked={'review': 2, 'approve': 1}
AssertionError: an answered request was asked again

On 1.20.0 and 1.21.0 the same script prints:

asks: ['review']
asks: ['approve']
agent-framework-core 1.21.0: outputs=[3], asked={'review': 1, 'approve': 1}

Package Versions

agent-framework-core: 1.22.0 (also main at ebcf4db)

Python Version

Python 3.13.9

Operating System

macOS

Regression

Yes

Additional Context

• Since 1.22.0, StepWrapper.__call__ first calls ctx._raise_if_current_task_interrupted(entering_step=True). Once any branch has paused (ctx._workflow_interruption is set), a step entered afterwards raises the run's interruption before it looks up its cached result or its response (ctx._get_response).
• If the request that step asks was answered in this run, the response is lost: _set_responses replaces ctx._responses on every run, and the next run is resumed with the responses to the requests it reported, which no longer include the answered one. The request is then asked again.
• Whether the step is entered before or after the sibling's pause depends on scheduling. Any await before a branch's request changes the interleaving; checkpoint storage with asynchronous writes (FileCheckpointStorage) is one such source. With it, two branches that each ask three requests in turn, with no other await, ask the first request of the second branch three times; with InMemoryCheckpointStorage they ask each request once.
• Possible directions: let a step whose request already has a response in this run proceed to consume it, or keep the responses of a run that were not consumed for the next resumption.
• Introduced with Python: Preserve concurrent steps across workflow pause #9291. Related to Python: [Bug]: Functional workflow raises a bare CancelledError when a step in a nested asyncio.gather starts after a sibling branch pauses for request_info #9516, where a step stopped at entry by the same check ends the run with a bare CancelledError inside a nested asyncio.gather. Not covered by Python: [Bug]: Functional workflow checkpoint replay returns a wrong cached result when a @step calls another @step #9385 or Python: [Bug]: An answered request_info is asked again under a new auto:: id when a sibling @step was running while it paused #9517, which concern cached step results and automatic request ids.

Acknowledgements

• I searched existing issues and did not find a duplicate.
• I personally verified this behavior and the reproduction details are authentic.
• I will wait for explicit maintainer agreement before starting implementation of a non-trivial change.