The workflow continued as new because cron has triggered a new execution.

The workflow continued as new because it is retrying.

The workflow itself requested to continue as new.

A request to cancel the Activity has occurred The SDK client will be able to confirm cancellation of an Activity during an Activity heartbeat.

Activity has been cancelled.

Activity Task has finished successfully The SDK client has picked up and successfully completed the Activity Task This event type contains Activity execution results.

Activity Task has finished unsuccessfully The SDK picked up the Activity Task but unsuccessfully completed it This event type contains Activity execution errors.

Activity Task was scheduled The SDK client should pick up this activity task and execute This event type contains activity inputs, as well as activity timeout configurations.

Activity Task has started executing The SDK client has picked up the Activity Task and is processing the Activity invocation.

Activity has timed out according to the Temporal Server Activity did not complete within the timeout settings.

Child Workflow execution has been cancelled.

Child Workflow execution has successfully completed.

Child Workflow execution has unsuccessfully completed.

Child Workflow execution has successfully started/triggered.

Child Workflow execution has been terminated.

Child Workflow execution has timed out by the Temporal Server.

Temporal Server has successfully requested the cancellation of the target Workflow.

Temporal Server has successfully Signaled the targeted Workflow.

A marker has been recorded.

Temporal Server could not cancel the targeted Workflow This is usually because the target Workflow could not be found.

Workflow has requested that the Temporal Server try to cancel another Workflow.

Temporal Server cannot Signal the targeted Workflow Usually because the Workflow could not be found.

Temporal Server will try to Signal the targeted Workflow Contains the Signal name, as well as a Signal payload.

Child Workflow execution cannot be started/triggered Usually due to a child Workflow ID collision.

Temporal Server will try to start a child Workflow.

A time has been cancelled.

A timer has fired.

A timer has started.

Place holder and should never appear in a Workflow execution history.

Workflow search attributes should be updated and synchronized with the visibility store.

A request has been made to cancel the Workflow execution.

SDK client has confirmed the cancellation request and the Workflow execution has been cancelled.

Workflow execution has successfully completed and contains Workflow execution results.

Workflow has successfully completed and a new Workflow has been started within the same transaction Contains last Workflow execution results as well as new Workflow execution inputs.

Workflow execution has unsuccessfully completed and contains the Workflow execution error.

Workflow has received a Signal event The event type contains the Signal name, as well as a Signal payload.

Workflow execution has been triggered/started It contains Workflow execution inputs, as well as Workflow timeout configurations.

Workflow execution has been forcefully terminated This is usually because the terminate Workflow API was called.

Workflow execution has timed out by the Temporal Server Usually due to the Workflow having not been completed within timeout settings.

Workflow Task has completed The SDK client picked up the Workflow Task and processed new history events SDK client may or may not ask the Temporal Server to do additional work, such as: EVENT_TYPE_ACTIVITY_TASK_SCHEDULED EVENT_TYPE_TIMER_STARTED EVENT_TYPE_UPSERT_WORKFLOW_SEARCH_ATTRIBUTES EVENT_TYPE_MARKER_RECORDED EVENT_TYPE_START_CHILD_WORKFLOW_EXECUTION_INITIATED EVENT_TYPE_REQUEST_CANCEL_EXTERNAL_WORKFLOW_EXECUTION_INITIATED EVENT_TYPE_SIGNAL_EXTERNAL_WORKFLOW_EXECUTION_INITIATED EVENT_TYPE_WORKFLOW_EXECUTION_COMPLETED EVENT_TYPE_WORKFLOW_EXECUTION_FAILED EVENT_TYPE_WORKFLOW_EXECUTION_CANCELED EVENT_TYPE_WORKFLOW_EXECUTION_CONTINUED_AS_NEW.

Workflow Task encountered a failure Usually this means that the Workflow was non-deterministic However, the Workflow reset functionality also uses this event.

Workflow Task has been scheduled and the SDK client should now be able to process any new history events.

Workflow Task has started and the SDK client has picked up the Workflow Task and is processing new history events.

Workflow Task encountered a timeout Either an SDK client with a local cache was not available at the time, or it took too long for the SDK client to process the task.

The child workflow will do nothing.

Cancellation will be requested of the child workflow.

The child workflow will also terminate.

None indicates that query should not be rejected.

NotCompletedCleanly indicates that query should be rejected if workflow did not complete cleanly.

NotOpen indicates that query should be rejected if workflow is not open.

Caller exceeds max concurrent request limit.

Caller exceeds request per second limit.

System overloaded.

SCHEDULE_OVERLAP_POLICY_ALLOW_ALL means start any number of concurrent workflows.

SCHEDULE_OVERLAP_POLICY_BUFFER_ALL means buffer up any number of starts to all happen sequentially, immediately after the running workflow completes.

SCHEDULE_OVERLAP_POLICY_BUFFER_ONE means start the workflow again soon as the current one completes, but only buffer one start in this way.

SCHEDULE_OVERLAP_POLICY_CANCEL_OTHER means that if there is another workflow running, cancel it, and start the new one after the old one completes cancellation.

SCHEDULE_OVERLAP_POLICY_SKIP (default) means don't start anything.

SCHEDULE_OVERLAP_POLICY_TERMINATE_OTHER means that if there is another workflow running, terminate it and start the new one immediately.

Tasks from a normal workflow task queue always include complete workflow history The task queue specified by the user is always a normal task queue.

A sticky queue only includes new history since the last workflow task, and they are per-worker.

Activity type of task queue.

Workflow type of task queue.

Value 1 is hardcoded in SQL persistence.

Allow starting a workflow execution using the same workflow id.

Allow starting a workflow execution using the same workflow id, only when the last execution's final state is one of [terminated, cancelled, timed out, failed].

Do not permit re-use of the workflow id for this workflow.

The worker encountered a mismatch while replaying history between what was expected, and what the workflow code actually did.

The worker wishes to fail the task and have the next one be generated on a normal, not sticky queue.

Between starting and completing the workflow task (with a workflow completion command), some new command (like a signal) was processed into workflow history.

Whenever this list of command types is changed do change the function shouldBufferEvent in mutableStateBuilder.go to make sure to do the correct event ordering.

Whenever this list of events is changed do change the function shouldBufferEvent in mutableStateBuilder.go to make sure to do the correct event ordering.

Defines how child workflows will react to their parent completing.

TODO: What is this?.

ScheduleOverlapPolicy controls what happens when a workflow would be started by a schedule, and is already running.

(-- api-linter: core::0216::synonyms=disabled aip.dev/not-precedent: There is WorkflowExecutionState already in another package.

Defines how new runs of a workflow with a particular ID may or may not be allowed.

Workflow tasks can fail for various reasons.