Repository navigation
Support async/await orchestrators across the Python SDK packages #294
Description
Summary
Support async def and await orchestrators across durabletask, durabletask.azuremanaged, and azure-functions-durable, including native two-argument and compatibility single-argument Functions orchestrators. Existing synchronous generator orchestrators remain supported.
Implementation: #293. Both authoring styles use the shared history/replay engine rather than separate provider runtimes.
Authoring model
from durabletask import task
async def sequence(ctx: task.OrchestrationContext, value: int) -> list[int]:
first = await ctx.call_activity("increment", input=value, return_type=int)
return await task.when_all([
ctx.call_activity("increment", input=first, return_type=int),
ctx.call_activity("increment", input=value, return_type=int),
])Durable operations remain the persistence boundary. Async helpers rerun during replay; a separate durable child instance uses call_sub_orchestrator. Deterministic asyncio composition and sleeps/timeouts are limited to the supported contract. Nondeterministic I/O belongs in ordinary activities, not orchestrators.
Acceptance criteria
- Native coroutine orchestrators work across all three packages and both Functions authoring styles.
- Generator orchestrators remain supported, including mixed generator/coroutine durable parents and children.
- Durable awaits preserve replay, result typing, retry, failure, payload, and entity-operation behavior.
- Deterministic composition, durable clocks/timers, timeouts, local cancellation, and dispatch cleanup have a defined supported contract.
- Documentation identifies unsupported APIs, framework-adapter responsibilities, and in-flight migration requirements without promising arbitrary async-library compatibility.
Local/virtual activities and automatic recording of arbitrary awaits are outside this feature. asyncio.wait and as_completed are not supported deterministic composition APIs.
Community feedback
Please share use cases and asyncio-library interoperability requirements in the discussion.
Activity
berndverst commentedon Oct 15, 2026
How do we avoid code duplication or breaking changes?
andystaples commentedon Oct 15, 2026
Follow-up exploration: virtual activities / recorded async calls
Preserving a design idea from the discussion of draft #293: an explicit local/virtual activity or recorded-side-effect boundary could let an orchestrator obtain the result of a nondeterministic async operation without rerunning that operation during replay.
The intended contract would be:
awaitexpressions may be too late: side effects may already have occurred.This is a separate exploration, not functionality implemented by the async/await prototype or an expansion of its supported await contract. Ordinary asyncio I/O remains unsupported inside orchestrators unless it is placed behind an appropriate durable boundary.
andystaples commentedon Oct 15, 2026
Bernd Verst (@berndverst) Check out the draft PR linked, it required no separate provider implementations and surprisingly little code duplication to get something functional. What remains to be seen is whether that approach continues to be viable as we address the remaining items. Breaking change risk with the current approach is also limited, given the minimally invasive edits needed to the replay logic itself but this would need to be carefully guarded - our test suite is a pretty good metric for this already. If we decide to continue down the draft PR's path, or adopt the additional functionality above, agreed, we'll need to be very careful about both before accepting anything
tamirdresher commentedon Oct 18, 2026
Big +1 on this andystaples / Bernd Verst (@berndverst) — while building the Durable Task / DTS extensions for LangGraph and Pydantic AI (
pydantic_ai.durable_exec), I hit this exact gap and ended up having to build a coroutine-to-generator bridge myself.In both frameworks (and especially Pydantic AI and
pydantic-graph), the entire agent loop and durability hook surface (BaseDurabilityCapability/RegisteredOperationBackend) isasync def-only: every model call, tool call, MCP call, and human-in-the-loop wait (wait_for_external_event) is awaited insideawait agent.run(...).Having
Taskbe natively awaitable and supportingasync deforchestrators in the SDK would let me drop a chunk of custom bridge code and let users compose durable agents directly withawaitinstead ofyield from.Two quick learnings from what I built that might be useful as we take this forward:
asyncio.gather/anyiotask groups (parallel tool calls): When an LLM returns multiple tool calls in one turn, Pydantic AI fans them out internally usinganyio.create_task_group()/asyncio.gather(), which callsasyncio.get_running_loop(). Purecoro.send()/throw()works great for sequentialawait ctx.call_activity(...), and to make framework-internalgather/TaskGroupwork I paired it with a tiny deterministic single-threadAbstractEventLoopshim (call_soonmicrotask queue only, no threads or selector I/O) that drains ready tasks in the current turn and coalesces the pendingTasks into a singletask.when_all(pending).Happy to share the trampoline / bridge code from the Pydantic AI & LangGraph prototypes if we want to compare notes or fold any of it in!
fix(worker): close orchestrator generators when a dispatch ends (#300)
andystaples commentedon Oct 30, 2026
#293 adds native
async deforchestrators across all three packages while retaining generator orchestrators and mixed-style durable children. The shared runtime supports orderedasyncio.gather, local tasks, durable sleeps/timeouts, and the documented asyncio/AnyIO task-group and cancellation paths.The async contract defines supported APIs, replay and migration requirements, and dispatch cleanup. Arbitrary I/O and automatic recording of ordinary async helpers are unsupported; nondeterministic work belongs in activities.
asyncio.waitandas_completedare outside the deterministic composition contract. Framework adapters retain activity registration, serialization, and replay-stable metadata responsibilities.tamirdresher commentedon Nov 1, 2026
Andy, this is great, thanks for putting it together so quickly. this also lines up with what the Pydantic maintainers asked for. Once we have this wired through, we should be able to remove most of the bridge and use a normal async orchestrator.
I noticed the proof uses a custom DurableModel and ReplayClock rather than our AzureDurableTaskDurability capability. That makes sense for the spike. The next step is to run the actual capability on top of this so we can see what still needs adapting on the harness side.
The main thing I want us to work through is parallel tool execution. Pydantic AI currently uses asyncio.wait with FIRST_COMPLETED and iterates the returned done set, while the proposed contract excludes wait and as_completed. Our bridge currently handles progress through when_any. Do you see a deterministic way to support that pattern in the SDK, or should we work with the Pydantic maintainers on changing it upstream? That will tell us whether we can keep this entirely within the harness.
We also need a public way to get the orchestration context from inside the capability, and to confirm how switching from a generator orchestrator to async works across continue as new while existing histories still replay. We can sort out the minimum SDK version when we’re ready to wire it in.
This looks like a good path to getting rid of the custom loop. Happy to take the Pydantic side and work through the remaining pieces together.