📄️ 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.
📄️ 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
| Workflows | Activities |
📄️ 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.