event history & replay

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

Version history provides summary of version information

Version history is a concept that provides a high level summary of version information regarding Workflow Execution History. Whenever there is a new Workflow Execution History entry generated, the version from the Namespace is attached. The Workflow Execution's mutable state keeps track of all history entries (events) and their corresponding versions.

Workflow Execution History modeled as tree in Multi-Cluster Replication

In Multi-Cluster Replication, Workflow Execution History Events are modeled as a tree structure. When Workflow Execution Histories diverge, they have more than one history branch. Among all history branches, the branch with the highest version is considered the current branch, and the Workflow Execution's mutable state is a summary of the current branch. When there is a switch between branches, a complete rebuild of the mutable state occurs.

External events re-injected during conflict resolution

During conflict resolution after failover, Temporal re-injects any external Events like Signals in the new Event History before discarding replication tasks. Even though some progress could roll back during failovers, Temporal provides the guarantee that Workflow Executions will not get stuck and will continue to make forward progress.

Zombie workflow state definition

A zombie state is one in which a Workflow Execution cannot be actively mutated by a Cluster (assuming the corresponding Namespace is active in that Cluster). A zombie Workflow Execution can only be changed by a replication Task. The zombie state is introduced because Temporal maintains a contract that for any Namespace and Workflow Id combination, there can be at most one run (Namespace + Workflow Id + Run Id) open/executing.

Zombie workflow creation scenario

Zombie Workflow Executions are created when different Runs (same Namespace and Workflow Id) arrive at a target Cluster out of order due to asynchronous replication. If Run 2 arrives before Run 1, Run 1 cannot be replicated as runnable due to the rule that at most one Run can be open for a Namespace + Workflow Id combination. Run 1 enters zombie state and can only be changed by a replication Task.

Workflow Task invalidation during conflict resolution

In Multi-Cluster Replication, tasks generated according to one Workflow Execution History branch may become invalidated by switching history branches during conflict resolution. Task processing logic verifies both the Event Id and version of the Task against the corresponding Workflow Execution's mutable state. If the Task's corresponding Event belongs to a non-current branch after conflict resolution, the task is discarded.

Task ordering scope note

Task Queue ordering applies only to the ordering of individual Tasks, and does not apply to the ordering of Workflow Executions, Activity Executions, or Events in a single Workflow Execution. The order of Events in a Workflow Execution is guaranteed to remain constant once they have been written to that Workflow Execution's History.

Give your agent this brain