workflow 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.

Non-determinism error causes Workflow execution to retry indefinitely

When a Non-determinism error occurs, the Workflow Task is retried over and over by the Temporal Service, loading up Workflow Workers. Affected Executions stop making progress and remain in Running status. This will not clear up on its own.

Non-determinism error identification in Event History

The WorkflowTaskFailed event in an affected Execution's Event History contains the message identifying exactly where replay diverged and which command was expected versus produced. This is the most direct signal for root cause of non-determinism errors.

Common causes of non-determinism errors

Non-determinism errors are commonly caused by: (1) Code changes that added, removed, or reordered commands such as Activity scheduling, Timers, Signals, or Child Workflows without a versioning guard; (2) Rolling restart with old and new Worker versions briefly running together; (3) Changed Activity or Timer parameters in existing Workflow code without versioning.

Non-determinism error metric tags

The temporal_workflow_task_execution_failed metric with failure_reason=NonDeterminismError carries tags for namespace, task_queue, and workflow_type but not Workflow Id.

High temporal_workflow_task_execution_latency causes

temporal_workflow_task_execution_latency measures time taken by a Worker to execute a Workflow Task. Temporal SDK raises 'Deadlock detected during Workflow run' error or TMPRL1101 when a Workflow Task takes more than one or two seconds. Causes include: CPU-intensive work in Workflow Task, slow local Activities (execution time includes Local Activity execution time), slow Workflow replay, Worker resource constraints (high CPU usage), infinite loops or blocking calls, and slow data conversion from custom Data Converter. Remediation: monitor Worker CPU and memory, ensure adequate resources, use profiler with replayer to identify CPU hot spots, review Workflow code for optimizations and blocking operations, disable deadlock detection for Data Converter (in Go use workflow.DataConverterWithoutDeadlockDetection, in Java wrap with WorkflowUnsafe.deadlockDetectorOff).

Blocking calls in Workflow code and slot exhaustion

A slot is held until the Workflow Task completes. Blocking I/O, heavy computation, or synchronous non-Temporal API calls inside a Workflow hold the slot far longer than expected. In the Python SDK, blocking the event loop in async def Workflow code will hold slots.

Give your agent this brain