First-class state machine workflow authoring across Java, TypeScript, and Python

[zhongkechen]

Request

Support authoring workflows with state machine semantics as a first-class construct in the Durable Functions SDKs for Java, TypeScript, and Python.

Context

The Durable Functions SDK currently provides an imperative programming model where workflows are authored as sequential or parallel code with checkpoint-and-replay. However, many real-world workflows are naturally modeled as state machines: explicit graphs of states, transitions, and terminal conditions.

There is currently no standard AWS abstraction for state machine authoring in the Durable Functions SDK beyond ASL (AWS Step Functions).

Why this is necessary

State machines are a fundamental workflow pattern

Many production workflows are modeled as state machines with explicit states, conditional transitions, retries, and terminal states. Forcing these workflows into an imperative model loses the clarity and operational reasoning that state machine semantics provide.

Loops in imperative code cause storage inefficiency

When state machine workflows with loops are expressed imperatively, the SDK must persist growing checkpoint data across replays to reconstruct loop iteration progress, including iteration counters, intermediate variables, and accumulated results.

As the number of iterations increases:

• Replay time increases because the full loop is re-executed in memory at each checkpoint
• Persisted state can grow without bound

In contrast, a native state machine model can persist only the current state and minimal transition outputs at each step, keeping snapshots compact and replay efficient regardless of iteration count.

Debugging and operational visibility degrade

In an imperative model, execution paths and transitions are implicit in code. Operators must read orchestration logic to understand all possible paths. A native state machine construct makes transitions explicit and inspectable, enabling better visualization, debugging, and operational tooling.

Desired capabilities

• A native state machine authoring construct, for example ctx.stateMachine(...), for defining states, transitions, and terminal states in standard code
• Efficient handling of loops by persisting only summarized transition state, such as the current state and minimal outputs, rather than full replay history
• Retry, parallel branches, and error transitions as first-class state machine concepts
• Interoperability with existing Durable Functions SDK constructs, including steps, waits, and callbacks
• Idiomatic APIs for Java, TypeScript, and Python