determinism & constraints

6 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Event History size limits and planning for Entity Workflows

Temporal enforces a hard limit of 51,200 Events and 50 MB per Workflow Execution, with warnings starting around 10,000 Events. Each Signal generates approximately 4 Events; each Activity execution generates approximately 11 Events. A loyalty entity processing 100 point accruals per day, each triggering one Activity, generates roughly 1,500 Events per day. Plan your Continue-As-New threshold accordingly.

Payload size limits in Temporal

Individual payloads for Workflow and Activity inputs and outputs are limited to 2 MB. If the serialized entity state approaches this limit, store large data externally and reference it by identifier.

Workflow Determinism requirements for non-deterministic operations

Workflows must be deterministic. Use workflow.now() instead of datetime.now(), workflow.random() instead of random, and workflow.uuid4() instead of uuid.uuid4(). All I/O must be performed in Activities, not in Workflow code.

Python SDK determinism requirements table

Do not use: datetime.now() — Use instead: workflow.now(). Do not use: random.random() — Use instead: workflow.random().random(). Do not use: uuid.uuid4() — Use instead: workflow.uuid4(). Do not use: time.sleep() — Use instead: asyncio.sleep() or workflow.sleep(). Do not use: print() — Use instead: workflow.logger.info(). Do not use: Direct I/O (HTTP, file reads) — Use instead: Activities.

disable_eager_activity_execution prevents bypassing rate-limited queues

Without disable_eager_activity_execution=True, Activities may bypass rate-limited Task Queues entirely. Eager execution runs Activities on the same Worker as the Workflow, which circumvents the rate limiting controls configured on Activity-specific Task Queues. Always disable eager execution when using rate-limited Task Queues for API calls.

WorkflowTaskFailed event and non-determinism

WorkflowTaskFailed event indicates that the Workflow Task encountered a failure. Usually this means that the Workflow was non-deterministic. However, the Workflow reset functionality also uses this Event. It has fields: scheduled_event_id (Id of WorkflowTaskScheduled Event this Workflow Task corresponds to), started_event_id (Id of WorkflowTaskStarted Event this Task corresponds to), failure (Details for Workflow Task's failure), identity (Identity of Worker that failed Task, must be explicitly defined to return value), base_run_id (Original Run Id of Workflow), new_run_id (Run Id of reset Workflow), fork_event_version (Identifies Event version forked off to reset Workflow), binary_checksum (Binary Id of Worker that failed Task, must be explicitly defined to return value).

Give your agent this brain