Overview
Workflows and activities live on opposite sides of the durable boundary and carry different constraints. Workflow code is replayed; activity code is retried. Those are not the same operation, and the rules flow from that split.
Idempotent vs. deterministic
In Durable Workflow 2.0, determinism keeps orchestration replay-safe while idempotency makes retried activity effects safe.
Execution Guarantees and Idempotency
The public v2 contract for replay, retries, lease expiry, redelivery, and the default idempotency surfaces.
Workflow Constraints
The determinism constraints for workflow classes dictate that a workflow class must not depend on external state or services that may change over time. This means that a workflow class should not perform any operations that rely on the current date and time, the current user, external network resources, or any other source of potentially changing state.
Activity Constraints
Activities are where workflow code crosses the durable boundary into IO and
Constraints Summary
What workflow and activity code may do.
Structural Limits
Structural limits cap the resource consumption of a single workflow run. When an operation would exceed a configured limit, the engine records a typed failure with a machine-readable structural_limit failure category and the specific limit kind, then fails the run. This protects the system from unbounded fan-out, oversized payloads, and metadata bloat.