📄️ Overview
The determinism and idempotency constraints for workflows and activities are important for ensuring the reliability and correctness of the overall system.
📄️ 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 have none of the prior constraints. However, because activities are retryable they should still be idempotent. If your activity creates a charge for a customer then retrying it should not create a duplicate charge.
📄️ 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.