package temporal.api.enums.v1
Get desktop application:
View/edit binary Protocol Buffers messages
Status of a standalone activity. The status is updated once, when the activity is originally scheduled, and again when the activity reaches a terminal status. (-- api-linter: core::0216::synonyms=disabled aip.dev/not-precedent: Named consistently with WorkflowExecutionStatus. --)
Used in: ,
ACTIVITY_EXECUTION_STATUS_UNSPECIFIED = 0
ACTIVITY_EXECUTION_STATUS_RUNNING = 1
The activity has not reached a terminal status. See PendingActivityState for the run state (SCHEDULED, STARTED, or CANCEL_REQUESTED).
ACTIVITY_EXECUTION_STATUS_COMPLETED = 2
The activity completed successfully. An activity can complete even after cancellation is requested if the worker calls RespondActivityTaskCompleted before acknowledging cancellation.
ACTIVITY_EXECUTION_STATUS_FAILED = 3
The activity failed. Causes: - Worker returned a non-retryable failure - RetryPolicy.maximum_attempts exhausted - Attempt failed after cancellation was requested (retries blocked)
ACTIVITY_EXECUTION_STATUS_CANCELED = 4
The activity was canceled. Reached when: - Cancellation requested while SCHEDULED (immediate), or - Cancellation requested while STARTED and worker called RespondActivityTaskCanceled. Workers discover cancellation requests via heartbeat responses (cancel_requested=true). Activities that do not heartbeat will not learn of cancellation and may complete, fail, or time out normally. CANCELED requires explicit worker acknowledgment or immediate cancellation of a SCHEDULED activity.
ACTIVITY_EXECUTION_STATUS_TERMINATED = 5
The activity was terminated. Immediate; does not wait for worker acknowledgment.
ACTIVITY_EXECUTION_STATUS_TIMED_OUT = 6
The activity timed out. See TimeoutType for the specific timeout. - SCHEDULE_TO_START and SCHEDULE_TO_CLOSE timeouts always result in TIMED_OUT. - START_TO_CLOSE and HEARTBEAT may retry if RetryPolicy permits; TIMED_OUT is reached when retry is blocked (RetryPolicy.maximum_attempts exhausted, SCHEDULE_TO_CLOSE would be exceeded, or cancellation has been requested).
Defines what to do when trying to start an activity with the same ID as a *running* activity. Note that it is *never* valid to have two running instances of the same activity ID. See `ActivityIdReusePolicy` for handling activity ID duplication with a *closed* activity.
Used in:
ACTIVITY_ID_CONFLICT_POLICY_UNSPECIFIED = 0
ACTIVITY_ID_CONFLICT_POLICY_FAIL = 1
Don't start a new activity; instead return `ActivityExecutionAlreadyStarted` error.
ACTIVITY_ID_CONFLICT_POLICY_USE_EXISTING = 2
Don't start a new activity; instead return a handle for the running activity.
Defines whether to allow re-using an activity ID from a previously *closed* activity. If the request is denied, the server returns an `ActivityExecutionAlreadyStarted` error. See `ActivityIdConflictPolicy` for handling ID duplication with a *running* activity.
Used in:
ACTIVITY_ID_REUSE_POLICY_UNSPECIFIED = 0
ACTIVITY_ID_REUSE_POLICY_ALLOW_DUPLICATE = 1
Always allow starting an activity using the same activity ID.
ACTIVITY_ID_REUSE_POLICY_ALLOW_DUPLICATE_FAILED_ONLY = 2
Allow starting an activity using the same ID only when the last activity's final state is one of {failed, canceled, terminated, timed out}.
ACTIVITY_ID_REUSE_POLICY_REJECT_DUPLICATE = 3
Do not permit re-use of the ID for this activity. Future start requests could potentially change the policy, allowing re-use of the ID.
Used in:
APPLICATION_ERROR_CATEGORY_UNSPECIFIED = 0
APPLICATION_ERROR_CATEGORY_BENIGN = 1
Expected application error with little/no severity.
Used in: ,
ARCHIVAL_STATE_UNSPECIFIED = 0
ARCHIVAL_STATE_DISABLED = 1
ARCHIVAL_STATE_ENABLED = 2
Used in: ,
BATCH_OPERATION_STATE_UNSPECIFIED = 0
BATCH_OPERATION_STATE_RUNNING = 1
BATCH_OPERATION_STATE_COMPLETED = 2
BATCH_OPERATION_STATE_FAILED = 3
Used in:
BATCH_OPERATION_TYPE_UNSPECIFIED = 0
BATCH_OPERATION_TYPE_TERMINATE = 1
BATCH_OPERATION_TYPE_CANCEL = 2
BATCH_OPERATION_TYPE_SIGNAL = 3
BATCH_OPERATION_TYPE_DELETE = 4
BATCH_OPERATION_TYPE_RESET = 5
BATCH_OPERATION_TYPE_UPDATE_EXECUTION_OPTIONS = 6
BATCH_OPERATION_TYPE_UNPAUSE_ACTIVITY = 7
BATCH_OPERATION_TYPE_UPDATE_ACTIVITY_OPTIONS = 8
BATCH_OPERATION_TYPE_RESET_ACTIVITY = 9
Specifies which category of tasks may reach a versioned worker of a certain Build ID. Task Reachability is eventually consistent; there may be a delay (up to few minutes) until it converges to the most accurate value but it is designed in a way to take the more conservative side until it converges. For example REACHABLE is more conservative than CLOSED_WORKFLOWS_ONLY. Note: future activities who inherit their workflow's Build ID but not its Task Queue will not be accounted for reachability as server cannot know if they'll happen as they do not use assignment rules of their Task Queue. Same goes for Child Workflows or Continue-As-New Workflows who inherit the parent/previous workflow's Build ID but not its Task Queue. In those cases, make sure to query reachability for the parent/previous workflow's Task Queue as well.
Used in:
BUILD_ID_TASK_REACHABILITY_UNSPECIFIED = 0
Task reachability is not reported
BUILD_ID_TASK_REACHABILITY_REACHABLE = 1
Build ID may be used by new workflows or activities (base on versioning rules), or there MAY be open workflows or backlogged activities assigned to it.
BUILD_ID_TASK_REACHABILITY_CLOSED_WORKFLOWS_ONLY = 2
Build ID does not have open workflows and is not reachable by new workflows, but MAY have closed workflows within the namespace retention period. Not applicable to activity-only task queues.
BUILD_ID_TASK_REACHABILITY_UNREACHABLE = 3
Build ID is not used for new executions, nor it has been used by any existing execution within the retention period.
State of a callback.
Used in: ,
CALLBACK_STATE_UNSPECIFIED = 0
Default value, unspecified state.
CALLBACK_STATE_STANDBY = 1
Callback is standing by, waiting to be triggered.
CALLBACK_STATE_SCHEDULED = 2
Callback is in the queue waiting to be executed or is currently executing.
CALLBACK_STATE_BACKING_OFF = 3
Callback has failed with a retryable error and is backing off before the next attempt.
CALLBACK_STATE_FAILED = 4
Callback has failed.
CALLBACK_STATE_SUCCEEDED = 5
Callback has succeeded.
CALLBACK_STATE_BLOCKED = 6
Callback is blocked (eg: by circuit breaker).
Used in:
CANCEL_EXTERNAL_WORKFLOW_EXECUTION_FAILED_CAUSE_UNSPECIFIED = 0
CANCEL_EXTERNAL_WORKFLOW_EXECUTION_FAILED_CAUSE_EXTERNAL_WORKFLOW_EXECUTION_NOT_FOUND = 1
CANCEL_EXTERNAL_WORKFLOW_EXECUTION_FAILED_CAUSE_NAMESPACE_NOT_FOUND = 2
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.
Used in:
COMMAND_TYPE_UNSPECIFIED = 0
COMMAND_TYPE_SCHEDULE_ACTIVITY_TASK = 1
COMMAND_TYPE_REQUEST_CANCEL_ACTIVITY_TASK = 2
COMMAND_TYPE_START_TIMER = 3
COMMAND_TYPE_COMPLETE_WORKFLOW_EXECUTION = 4
COMMAND_TYPE_FAIL_WORKFLOW_EXECUTION = 5
COMMAND_TYPE_CANCEL_TIMER = 6
COMMAND_TYPE_CANCEL_WORKFLOW_EXECUTION = 7
COMMAND_TYPE_REQUEST_CANCEL_EXTERNAL_WORKFLOW_EXECUTION = 8
COMMAND_TYPE_RECORD_MARKER = 9
COMMAND_TYPE_CONTINUE_AS_NEW_WORKFLOW_EXECUTION = 10
COMMAND_TYPE_START_CHILD_WORKFLOW_EXECUTION = 11
COMMAND_TYPE_SIGNAL_EXTERNAL_WORKFLOW_EXECUTION = 12
COMMAND_TYPE_UPSERT_WORKFLOW_SEARCH_ATTRIBUTES = 13
COMMAND_TYPE_PROTOCOL_MESSAGE = 14
COMMAND_TYPE_MODIFY_WORKFLOW_PROPERTIES = 16
COMMAND_TYPE_SCHEDULE_NEXUS_OPERATION = 17
COMMAND_TYPE_REQUEST_CANCEL_NEXUS_OPERATION = 18
Used in: , ,
CONTINUE_AS_NEW_INITIATOR_UNSPECIFIED = 0
CONTINUE_AS_NEW_INITIATOR_WORKFLOW = 1
The workflow itself requested to continue as new
CONTINUE_AS_NEW_INITIATOR_RETRY = 2
The workflow continued as new because it is retrying
CONTINUE_AS_NEW_INITIATOR_CRON_SCHEDULE = 3
The workflow continued as new because cron has triggered a new execution
Experimental. Defines the versioning behavior to be used by the first task of a new workflow run in a continue-as-new chain.
Used in: , , ,
CONTINUE_AS_NEW_VERSIONING_BEHAVIOR_UNSPECIFIED = 0
CONTINUE_AS_NEW_VERSIONING_BEHAVIOR_AUTO_UPGRADE = 1
Experimental. Start the new run with AutoUpgrade behavior. Use the Target Version of the workflow's task queue at start-time, as AutoUpgrade workflows do. After the first workflow task completes, use whatever Versioning Behavior the workflow is annotated with in the workflow code. Note that if the workflow being continued has a Pinned override, that override will be inherited by the new workflow run regardless of the ContinueAsNewVersioningBehavior specified in the continue-as-new command. Versioning Override always takes precedence until it's removed manually via UpdateWorkflowExecutionOptions.
CONTINUE_AS_NEW_VERSIONING_BEHAVIOR_USE_RAMPING_VERSION = 2
Experimental. Use the Ramping Version of the workflow's task queue at start time, regardless of the workflow's Target Version (according to f(workflow_id, ramp_percentage)). After the first workflow task completes, the workflow will use whatever Versioning Behavior it is annotated with. If there is no Ramping Version by the time that the first workflow task is dispatched, it will be sent to the Current Version. It is highly discouraged to use this if the workflow is annotated with AutoUpgrade behavior, because this setting ONLY applies to the first task of the workflow. If, after the first task, the workflow is AutoUpgrade, it will behave like a normal AutoUpgrade workflow and go to the Target Version, which may be the Current Version instead of the Ramping Version. Note that if the workflow being continued has a Pinned override, that override will be inherited by the new workflow run regardless of the ContinueAsNewVersioningBehavior specified in the continue-as-new command. Versioning Override always takes precedence until it's removed manually via UpdateWorkflowExecutionOptions.
Specify the reachability level for a deployment so users can decide if it is time to decommission the deployment.
Used in:
DEPLOYMENT_REACHABILITY_UNSPECIFIED = 0
Reachability level is not specified.
DEPLOYMENT_REACHABILITY_REACHABLE = 1
The deployment is reachable by new and/or open workflows. The deployment cannot be decommissioned safely.
DEPLOYMENT_REACHABILITY_CLOSED_WORKFLOWS_ONLY = 2
The deployment is not reachable by new or open workflows, but might be still needed by Queries sent to closed workflows. The deployment can be decommissioned safely if user does not query closed workflows.
DEPLOYMENT_REACHABILITY_UNREACHABLE = 3
The deployment is not reachable by any workflow because all the workflows who needed this deployment went out of retention period. The deployment can be decommissioned safely.
Used in:
DESCRIBE_TASK_QUEUE_MODE_UNSPECIFIED = 0
Unspecified means legacy behavior.
DESCRIBE_TASK_QUEUE_MODE_ENHANCED = 1
Enhanced mode reports aggregated results for all partitions, supports Build IDs, and reports richer info.
Used in:
ENCODING_TYPE_UNSPECIFIED = 0
ENCODING_TYPE_PROTO3 = 1
ENCODING_TYPE_JSON = 2
Whenever this list of events is changed do change the function shouldBufferEvent in mutableStateBuilder.go to make sure to do the correct event ordering
Used in: , , ,
EVENT_TYPE_UNSPECIFIED = 0
Place holder and should never appear in a Workflow execution history
EVENT_TYPE_WORKFLOW_EXECUTION_STARTED = 1
Workflow execution has been triggered/started It contains Workflow execution inputs, as well as Workflow timeout configurations
EVENT_TYPE_WORKFLOW_EXECUTION_COMPLETED = 2
Workflow execution has successfully completed and contains Workflow execution results
EVENT_TYPE_WORKFLOW_EXECUTION_FAILED = 3
Workflow execution has unsuccessfully completed and contains the Workflow execution error
EVENT_TYPE_WORKFLOW_EXECUTION_TIMED_OUT = 4
Workflow execution has timed out by the Temporal Server Usually due to the Workflow having not been completed within timeout settings
EVENT_TYPE_WORKFLOW_TASK_SCHEDULED = 5
Workflow Task has been scheduled and the SDK client should now be able to process any new history events
EVENT_TYPE_WORKFLOW_TASK_STARTED = 6
Workflow Task has started and the SDK client has picked up the Workflow Task and is processing new history events
EVENT_TYPE_WORKFLOW_TASK_COMPLETED = 7
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
EVENT_TYPE_WORKFLOW_TASK_TIMED_OUT = 8
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
EVENT_TYPE_WORKFLOW_TASK_FAILED = 9
Workflow Task encountered a failure Usually this means that the Workflow was non-deterministic However, the Workflow reset functionality also uses this event
EVENT_TYPE_ACTIVITY_TASK_SCHEDULED = 10
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
EVENT_TYPE_ACTIVITY_TASK_STARTED = 11
Activity Task has started executing The SDK client has picked up the Activity Task and is processing the Activity invocation
EVENT_TYPE_ACTIVITY_TASK_COMPLETED = 12
Activity Task has finished successfully The SDK client has picked up and successfully completed the Activity Task This event type contains Activity execution results
EVENT_TYPE_ACTIVITY_TASK_FAILED = 13
Activity Task has finished unsuccessfully The SDK picked up the Activity Task but unsuccessfully completed it This event type contains Activity execution errors
EVENT_TYPE_ACTIVITY_TASK_TIMED_OUT = 14
Activity has timed out according to the Temporal Server Activity did not complete within the timeout settings
EVENT_TYPE_ACTIVITY_TASK_CANCEL_REQUESTED = 15
A request to cancel the Activity has occurred The SDK client will be able to confirm cancellation of an Activity during an Activity heartbeat
EVENT_TYPE_ACTIVITY_TASK_CANCELED = 16
Activity has been cancelled
EVENT_TYPE_TIMER_STARTED = 17
A timer has started
EVENT_TYPE_TIMER_FIRED = 18
A timer has fired
EVENT_TYPE_TIMER_CANCELED = 19
A time has been cancelled
EVENT_TYPE_WORKFLOW_EXECUTION_CANCEL_REQUESTED = 20
A request has been made to cancel the Workflow execution
EVENT_TYPE_WORKFLOW_EXECUTION_CANCELED = 21
SDK client has confirmed the cancellation request and the Workflow execution has been cancelled
EVENT_TYPE_REQUEST_CANCEL_EXTERNAL_WORKFLOW_EXECUTION_INITIATED = 22
Workflow has requested that the Temporal Server try to cancel another Workflow
EVENT_TYPE_REQUEST_CANCEL_EXTERNAL_WORKFLOW_EXECUTION_FAILED = 23
Temporal Server could not cancel the targeted Workflow This is usually because the target Workflow could not be found
EVENT_TYPE_EXTERNAL_WORKFLOW_EXECUTION_CANCEL_REQUESTED = 24
Temporal Server has successfully requested the cancellation of the target Workflow
EVENT_TYPE_MARKER_RECORDED = 25
A marker has been recorded. This event type is transparent to the Temporal Server The Server will only store it and will not try to understand it.
EVENT_TYPE_WORKFLOW_EXECUTION_SIGNALED = 26
Workflow has received a Signal event The event type contains the Signal name, as well as a Signal payload
EVENT_TYPE_WORKFLOW_EXECUTION_TERMINATED = 27
Workflow execution has been forcefully terminated This is usually because the terminate Workflow API was called
EVENT_TYPE_WORKFLOW_EXECUTION_CONTINUED_AS_NEW = 28
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
EVENT_TYPE_START_CHILD_WORKFLOW_EXECUTION_INITIATED = 29
Temporal Server will try to start a child Workflow
EVENT_TYPE_START_CHILD_WORKFLOW_EXECUTION_FAILED = 30
Child Workflow execution cannot be started/triggered Usually due to a child Workflow ID collision
EVENT_TYPE_CHILD_WORKFLOW_EXECUTION_STARTED = 31
Child Workflow execution has successfully started/triggered
EVENT_TYPE_CHILD_WORKFLOW_EXECUTION_COMPLETED = 32
Child Workflow execution has successfully completed
EVENT_TYPE_CHILD_WORKFLOW_EXECUTION_FAILED = 33
Child Workflow execution has unsuccessfully completed
EVENT_TYPE_CHILD_WORKFLOW_EXECUTION_CANCELED = 34
Child Workflow execution has been cancelled
EVENT_TYPE_CHILD_WORKFLOW_EXECUTION_TIMED_OUT = 35
Child Workflow execution has timed out by the Temporal Server
EVENT_TYPE_CHILD_WORKFLOW_EXECUTION_TERMINATED = 36
Child Workflow execution has been terminated
EVENT_TYPE_SIGNAL_EXTERNAL_WORKFLOW_EXECUTION_INITIATED = 37
Temporal Server will try to Signal the targeted Workflow Contains the Signal name, as well as a Signal payload
EVENT_TYPE_SIGNAL_EXTERNAL_WORKFLOW_EXECUTION_FAILED = 38
Temporal Server cannot Signal the targeted Workflow Usually because the Workflow could not be found
EVENT_TYPE_EXTERNAL_WORKFLOW_EXECUTION_SIGNALED = 39
Temporal Server has successfully Signaled the targeted Workflow
EVENT_TYPE_UPSERT_WORKFLOW_SEARCH_ATTRIBUTES = 40
Workflow search attributes should be updated and synchronized with the visibility store
EVENT_TYPE_WORKFLOW_EXECUTION_UPDATE_ADMITTED = 47
An update was admitted. Note that not all admitted updates result in this event. See UpdateAdmittedEventOrigin for situations in which this event is created.
EVENT_TYPE_WORKFLOW_EXECUTION_UPDATE_ACCEPTED = 41
An update was accepted (i.e. passed validation, perhaps because no validator was defined)
EVENT_TYPE_WORKFLOW_EXECUTION_UPDATE_REJECTED = 42
This event is never written to history.
EVENT_TYPE_WORKFLOW_EXECUTION_UPDATE_COMPLETED = 43
An update completed
EVENT_TYPE_WORKFLOW_PROPERTIES_MODIFIED_EXTERNALLY = 44
Some property or properties of the workflow as a whole have changed by non-workflow code. The distinction of external vs. command-based modification is important so the SDK can maintain determinism when using the command-based approach.
EVENT_TYPE_ACTIVITY_PROPERTIES_MODIFIED_EXTERNALLY = 45
Some property or properties of an already-scheduled activity have changed by non-workflow code. The distinction of external vs. command-based modification is important so the SDK can maintain determinism when using the command-based approach.
EVENT_TYPE_WORKFLOW_PROPERTIES_MODIFIED = 46
Workflow properties modified by user workflow code
EVENT_TYPE_NEXUS_OPERATION_SCHEDULED = 48
A Nexus operation was scheduled using a ScheduleNexusOperation command.
EVENT_TYPE_NEXUS_OPERATION_STARTED = 49
An asynchronous Nexus operation was started by a Nexus handler.
EVENT_TYPE_NEXUS_OPERATION_COMPLETED = 50
A Nexus operation completed successfully.
EVENT_TYPE_NEXUS_OPERATION_FAILED = 51
A Nexus operation failed.
EVENT_TYPE_NEXUS_OPERATION_CANCELED = 52
A Nexus operation completed as canceled.
EVENT_TYPE_NEXUS_OPERATION_TIMED_OUT = 53
A Nexus operation timed out.
EVENT_TYPE_NEXUS_OPERATION_CANCEL_REQUESTED = 54
A Nexus operation was requested to be canceled using a RequestCancelNexusOperation command.
EVENT_TYPE_WORKFLOW_EXECUTION_OPTIONS_UPDATED = 55
Workflow execution options updated by user.
EVENT_TYPE_NEXUS_OPERATION_CANCEL_REQUEST_COMPLETED = 56
A cancellation request for a Nexus operation was successfully delivered to the Nexus handler.
EVENT_TYPE_NEXUS_OPERATION_CANCEL_REQUEST_FAILED = 57
A cancellation request for a Nexus operation resulted in an error.
EVENT_TYPE_WORKFLOW_EXECUTION_PAUSED = 58
An event that indicates that the workflow execution has been paused.
EVENT_TYPE_WORKFLOW_EXECUTION_UNPAUSED = 59
An event that indicates that the previously paused workflow execution has been unpaused.
EVENT_TYPE_WORKFLOW_EXECUTION_TIME_SKIPPING_TRANSITIONED = 60
An event that indicates time skipping advanced time or was disabled automatically after a bound was reached.
Used in:
HISTORY_EVENT_FILTER_TYPE_UNSPECIFIED = 0
HISTORY_EVENT_FILTER_TYPE_ALL_EVENT = 1
HISTORY_EVENT_FILTER_TYPE_CLOSE_EVENT = 2
Used in: , ,
INDEXED_VALUE_TYPE_UNSPECIFIED = 0
INDEXED_VALUE_TYPE_TEXT = 1
INDEXED_VALUE_TYPE_KEYWORD = 2
INDEXED_VALUE_TYPE_INT = 3
INDEXED_VALUE_TYPE_DOUBLE = 4
INDEXED_VALUE_TYPE_BOOL = 5
INDEXED_VALUE_TYPE_DATETIME = 6
INDEXED_VALUE_TYPE_KEYWORD_LIST = 7
Used in: , ,
NAMESPACE_STATE_UNSPECIFIED = 0
NAMESPACE_STATE_REGISTERED = 1
NAMESPACE_STATE_DEPRECATED = 2
NAMESPACE_STATE_DELETED = 3
NexusHandlerErrorRetryBehavior allows nexus handlers to explicity set the retry behavior of a HandlerError. If not specified, retry behavior is determined from the error type. For example internal errors are not retryable by default unless specified otherwise.
Used in: ,
NEXUS_HANDLER_ERROR_RETRY_BEHAVIOR_UNSPECIFIED = 0
NEXUS_HANDLER_ERROR_RETRY_BEHAVIOR_RETRYABLE = 1
A handler error is explicitly marked as retryable.
NEXUS_HANDLER_ERROR_RETRY_BEHAVIOR_NON_RETRYABLE = 2
A handler error is explicitly marked as non-retryable.
State of a Nexus operation cancellation.
Used in: ,
NEXUS_OPERATION_CANCELLATION_STATE_UNSPECIFIED = 0
Default value, unspecified state.
NEXUS_OPERATION_CANCELLATION_STATE_SCHEDULED = 1
Cancellation request is in the queue waiting to be executed or is currently executing.
NEXUS_OPERATION_CANCELLATION_STATE_BACKING_OFF = 2
Cancellation request has failed with a retryable error and is backing off before the next attempt.
NEXUS_OPERATION_CANCELLATION_STATE_SUCCEEDED = 3
Cancellation request succeeded.
NEXUS_OPERATION_CANCELLATION_STATE_FAILED = 4
Cancellation request failed with a non-retryable error.
NEXUS_OPERATION_CANCELLATION_STATE_TIMED_OUT = 5
The associated operation timed out - exceeded the user supplied schedule-to-close timeout.
NEXUS_OPERATION_CANCELLATION_STATE_BLOCKED = 6
Cancellation request is blocked (eg: by circuit breaker).
Status of a standalone Nexus operation execution. The status is updated once, when the operation is originally scheduled, and again when the operation reaches a terminal status. (-- api-linter: core::0216::synonyms=disabled aip.dev/not-precedent: Named consistently with WorkflowExecutionStatus. --)
Used in: ,
NEXUS_OPERATION_EXECUTION_STATUS_UNSPECIFIED = 0
NEXUS_OPERATION_EXECUTION_STATUS_RUNNING = 1
The operation is not in a terminal status. The operation may be attempting to start, backing off between attempts, or already started.
NEXUS_OPERATION_EXECUTION_STATUS_COMPLETED = 2
The operation completed successfully.
NEXUS_OPERATION_EXECUTION_STATUS_FAILED = 3
The operation completed with failure.
NEXUS_OPERATION_EXECUTION_STATUS_CANCELED = 4
The operation completed as canceled. Requesting to cancel an operation does not automatically transition the operation to canceled status, depending on the current operation status and the cancelation type used.
NEXUS_OPERATION_EXECUTION_STATUS_TERMINATED = 5
The operation was terminated. Termination happens immediately without notifying the handler.
NEXUS_OPERATION_EXECUTION_STATUS_TIMED_OUT = 6
The operation has timed out by reaching one of the specified timeouts.
Defines what to do when trying to start a Nexus operation with the same ID as a *running* operation. Note that it is *never* valid to have two running instances of the same operation ID. See `NexusOperationIdReusePolicy` for handling operation ID duplication with a *closed* operation.
Used in:
NEXUS_OPERATION_ID_CONFLICT_POLICY_UNSPECIFIED = 0
NEXUS_OPERATION_ID_CONFLICT_POLICY_FAIL = 1
Don't start a new operation; instead return `NexusOperationAlreadyStarted` error.
NEXUS_OPERATION_ID_CONFLICT_POLICY_USE_EXISTING = 2
Don't start a new operation; instead return a handle for the running operation.
Defines whether to allow re-using an operation ID from a previously *closed* Nexus operation. If the request is denied, the server returns a `NexusOperationAlreadyStarted` error. See `NexusOperationIdConflictPolicy` for handling ID duplication with a *running* operation.
Used in:
NEXUS_OPERATION_ID_REUSE_POLICY_UNSPECIFIED = 0
NEXUS_OPERATION_ID_REUSE_POLICY_ALLOW_DUPLICATE = 1
Always allow starting an operation using the same operation ID.
NEXUS_OPERATION_ID_REUSE_POLICY_ALLOW_DUPLICATE_FAILED_ONLY = 2
Allow starting an operation using the same ID only when the last operation's final state is one of {failed, canceled, terminated, timed out}.
NEXUS_OPERATION_ID_REUSE_POLICY_REJECT_DUPLICATE = 3
Do not permit re-use of the ID for this operation. Future start requests could potentially change the policy, allowing re-use of the ID.
Stage that can be specified when waiting on a nexus operation.
Used in: ,
NEXUS_OPERATION_WAIT_STAGE_UNSPECIFIED = 0
NEXUS_OPERATION_WAIT_STAGE_STARTED = 1
Wait for the operation to be started.
NEXUS_OPERATION_WAIT_STAGE_CLOSED = 2
Wait for the operation to be in a terminal state, either successful or unsuccessful.
Defines how child workflows will react to their parent completing
Used in: , ,
PARENT_CLOSE_POLICY_UNSPECIFIED = 0
PARENT_CLOSE_POLICY_TERMINATE = 1
The child workflow will also terminate
PARENT_CLOSE_POLICY_ABANDON = 2
The child workflow will do nothing
PARENT_CLOSE_POLICY_REQUEST_CANCEL = 3
Cancellation will be requested of the child workflow
Used in: ,
PENDING_ACTIVITY_STATE_UNSPECIFIED = 0
PENDING_ACTIVITY_STATE_SCHEDULED = 1
PENDING_ACTIVITY_STATE_STARTED = 2
PENDING_ACTIVITY_STATE_CANCEL_REQUESTED = 3
PENDING_ACTIVITY_STATE_PAUSED = 4
PAUSED means activity is paused on the server, and is not running in the worker
PENDING_ACTIVITY_STATE_PAUSE_REQUESTED = 5
PAUSE_REQUESTED means activity is currently running on the worker, but paused on the server
State of a pending Nexus operation.
Used in: ,
PENDING_NEXUS_OPERATION_STATE_UNSPECIFIED = 0
Default value, unspecified state.
PENDING_NEXUS_OPERATION_STATE_SCHEDULED = 1
Operation is in the queue waiting to be executed or is currently executing.
PENDING_NEXUS_OPERATION_STATE_BACKING_OFF = 2
Operation has failed with a retryable error and is backing off before the next attempt.
PENDING_NEXUS_OPERATION_STATE_STARTED = 3
Operation was started and will complete asynchronously.
PENDING_NEXUS_OPERATION_STATE_BLOCKED = 4
Operation is blocked (eg: by circuit breaker).
Used in:
PENDING_WORKFLOW_TASK_STATE_UNSPECIFIED = 0
PENDING_WORKFLOW_TASK_STATE_SCHEDULED = 1
PENDING_WORKFLOW_TASK_STATE_STARTED = 2
Used in:
QUERY_REJECT_CONDITION_UNSPECIFIED = 0
QUERY_REJECT_CONDITION_NONE = 1
None indicates that query should not be rejected.
QUERY_REJECT_CONDITION_NOT_OPEN = 2
NotOpen indicates that query should be rejected if workflow is not open.
QUERY_REJECT_CONDITION_NOT_COMPLETED_CLEANLY = 3
NotCompletedCleanly indicates that query should be rejected if workflow did not complete cleanly.
Used in: ,
QUERY_RESULT_TYPE_UNSPECIFIED = 0
QUERY_RESULT_TYPE_ANSWERED = 1
QUERY_RESULT_TYPE_FAILED = 2
Source for the effective rate limit.
Used in:
RATE_LIMIT_SOURCE_UNSPECIFIED = 0
RATE_LIMIT_SOURCE_API = 1
The value was set by the API.
RATE_LIMIT_SOURCE_WORKER = 2
The value was set by a worker.
RATE_LIMIT_SOURCE_SYSTEM = 3
The value was set as the system default.
Used in:
REPLICATION_STATE_UNSPECIFIED = 0
REPLICATION_STATE_NORMAL = 1
REPLICATION_STATE_HANDOVER = 2
Event types to exclude when reapplying events beyond the reset point.
Used in: ,
RESET_REAPPLY_EXCLUDE_TYPE_UNSPECIFIED = 0
RESET_REAPPLY_EXCLUDE_TYPE_SIGNAL = 1
Exclude signals when reapplying events beyond the reset point.
RESET_REAPPLY_EXCLUDE_TYPE_UPDATE = 2
Exclude updates when reapplying events beyond the reset point.
RESET_REAPPLY_EXCLUDE_TYPE_NEXUS = 3
Exclude nexus events when reapplying events beyond the reset point.
RESET_REAPPLY_EXCLUDE_TYPE_CANCEL_REQUEST = 4
Deprecated, unimplemented option.
Deprecated: applications should use ResetReapplyExcludeType to specify exclusions from this set, and new event types should be added to ResetReapplyExcludeType instead of here.
Used in: , ,
RESET_REAPPLY_TYPE_UNSPECIFIED = 0
RESET_REAPPLY_TYPE_SIGNAL = 1
Signals are reapplied when workflow is reset.
RESET_REAPPLY_TYPE_NONE = 2
No events are reapplied when workflow is reset.
RESET_REAPPLY_TYPE_ALL_ELIGIBLE = 3
All eligible events are reapplied when workflow is reset.
Deprecated, see temporal.api.common.v1.ResetOptions.
Used in:
RESET_TYPE_UNSPECIFIED = 0
RESET_TYPE_FIRST_WORKFLOW_TASK = 1
Resets to event of the first workflow task completed, or if it does not exist, the event after task scheduled.
RESET_TYPE_LAST_WORKFLOW_TASK = 2
Resets to event of the last workflow task completed, or if it does not exist, the event after task scheduled.
Used in:
RESOURCE_EXHAUSTED_CAUSE_UNSPECIFIED = 0
RESOURCE_EXHAUSTED_CAUSE_RPS_LIMIT = 1
Caller exceeds request per second limit.
RESOURCE_EXHAUSTED_CAUSE_CONCURRENT_LIMIT = 2
Caller exceeds max concurrent request limit.
RESOURCE_EXHAUSTED_CAUSE_SYSTEM_OVERLOADED = 3
System overloaded.
RESOURCE_EXHAUSTED_CAUSE_PERSISTENCE_LIMIT = 4
Namespace exceeds persistence rate limit.
RESOURCE_EXHAUSTED_CAUSE_BUSY_WORKFLOW = 5
Workflow is busy
RESOURCE_EXHAUSTED_CAUSE_APS_LIMIT = 6
Caller exceeds action per second limit.
RESOURCE_EXHAUSTED_CAUSE_PERSISTENCE_STORAGE_LIMIT = 7
Persistence storage limit exceeded.
RESOURCE_EXHAUSTED_CAUSE_CIRCUIT_BREAKER_OPEN = 8
Circuit breaker is open/half-open.
RESOURCE_EXHAUSTED_CAUSE_OPS_LIMIT = 9
Namespace exceeds operations rate limit.
RESOURCE_EXHAUSTED_CAUSE_WORKER_DEPLOYMENT_LIMITS = 10
Limits related to Worker Deployments are reached.
Used in:
RESOURCE_EXHAUSTED_SCOPE_UNSPECIFIED = 0
RESOURCE_EXHAUSTED_SCOPE_NAMESPACE = 1
Exhausted resource is a system-level resource.
RESOURCE_EXHAUSTED_SCOPE_SYSTEM = 2
Exhausted resource is a namespace-level resource.
Used in: , , , , , , ,
RETRY_STATE_UNSPECIFIED = 0
RETRY_STATE_IN_PROGRESS = 1
RETRY_STATE_NON_RETRYABLE_FAILURE = 2
RETRY_STATE_TIMEOUT = 3
RETRY_STATE_MAXIMUM_ATTEMPTS_REACHED = 4
RETRY_STATE_RETRY_POLICY_NOT_SET = 5
RETRY_STATE_INTERNAL_SERVER_ERROR = 6
RETRY_STATE_CANCEL_REQUESTED = 7
Indicates whether a change to the Routing Config has been propagated to all relevant Task Queues and their partitions.
Used in:
ROUTING_CONFIG_UPDATE_STATE_UNSPECIFIED = 0
ROUTING_CONFIG_UPDATE_STATE_IN_PROGRESS = 1
Update to the RoutingConfig is currently in progress.
ROUTING_CONFIG_UPDATE_STATE_COMPLETED = 2
Update to the RoutingConfig has completed successfully.
ScheduleOverlapPolicy controls what happens when a workflow would be started by a schedule, and is already running.
Used in: , ,
SCHEDULE_OVERLAP_POLICY_UNSPECIFIED = 0
SCHEDULE_OVERLAP_POLICY_SKIP = 1
SCHEDULE_OVERLAP_POLICY_SKIP (default) means don't start anything. When the workflow completes, the next scheduled event after that time will be considered.
SCHEDULE_OVERLAP_POLICY_BUFFER_ONE = 2
SCHEDULE_OVERLAP_POLICY_BUFFER_ONE means start the workflow again soon as the current one completes, but only buffer one start in this way. If another start is supposed to happen when the workflow is running, and one is already buffered, then only the first one will be started after the running workflow finishes.
SCHEDULE_OVERLAP_POLICY_BUFFER_ALL = 3
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_CANCEL_OTHER = 4
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_TERMINATE_OTHER = 5
SCHEDULE_OVERLAP_POLICY_TERMINATE_OTHER means that if there is another workflow running, terminate it and start the new one immediately.
SCHEDULE_OVERLAP_POLICY_ALLOW_ALL = 6
SCHEDULE_OVERLAP_POLICY_ALLOW_ALL means start any number of concurrent workflows. Note that with this policy, last completion result and last failure will not be available since workflows are not sequential.
Used in:
SEVERITY_UNSPECIFIED = 0
SEVERITY_HIGH = 1
SEVERITY_MEDIUM = 2
SEVERITY_LOW = 3
Used in:
SIGNAL_EXTERNAL_WORKFLOW_EXECUTION_FAILED_CAUSE_UNSPECIFIED = 0
SIGNAL_EXTERNAL_WORKFLOW_EXECUTION_FAILED_CAUSE_EXTERNAL_WORKFLOW_EXECUTION_NOT_FOUND = 1
SIGNAL_EXTERNAL_WORKFLOW_EXECUTION_FAILED_CAUSE_NAMESPACE_NOT_FOUND = 2
SIGNAL_EXTERNAL_WORKFLOW_EXECUTION_FAILED_CAUSE_SIGNAL_COUNT_LIMIT_EXCEEDED = 3
Signal count limit is per workflow and controlled by server dynamic config "history.maximumSignalsPerExecution"
Used in:
START_CHILD_WORKFLOW_EXECUTION_FAILED_CAUSE_UNSPECIFIED = 0
START_CHILD_WORKFLOW_EXECUTION_FAILED_CAUSE_WORKFLOW_ALREADY_EXISTS = 1
START_CHILD_WORKFLOW_EXECUTION_FAILED_CAUSE_NAMESPACE_NOT_FOUND = 2
SuggestContinueAsNewReason specifies why SuggestContinueAsNew is true.
Used in:
SUGGEST_CONTINUE_AS_NEW_REASON_UNSPECIFIED = 0
SUGGEST_CONTINUE_AS_NEW_REASON_HISTORY_SIZE_TOO_LARGE = 1
Workflow History size is getting too large.
SUGGEST_CONTINUE_AS_NEW_REASON_TOO_MANY_HISTORY_EVENTS = 2
Workflow History event count is getting too large.
SUGGEST_CONTINUE_AS_NEW_REASON_TOO_MANY_UPDATES = 3
Workflow's count of completed plus in-flight updates is too large.
Used in:
TASK_QUEUE_KIND_UNSPECIFIED = 0
Tasks from any non workflow task may be unspecified. Task queue kind is used to differentiate whether a workflow task queue is sticky or normal. If a task is not a workflow task, Task queue kind will sometimes be unspecified.
TASK_QUEUE_KIND_NORMAL = 1
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. There can be as many workers as desired for a single normal task queue. All those workers may pick up tasks from that queue.
TASK_QUEUE_KIND_STICKY = 2
A sticky queue only includes new history since the last workflow task, and they are per-worker. Sticky queues are created dynamically by each worker during their start up. They only exist for the lifetime of the worker process. Tasks in a sticky task queue are only available to the worker that created the sticky queue. Sticky queues are only for workflow tasks. There are no sticky task queues for activities.
TASK_QUEUE_KIND_WORKER_COMMANDS = 3
A worker-commands task queue is used for server-to-worker communication (e.g. activity cancellations). These queues are ephemeral and per-worker-process — they exist only for the lifetime of the worker process. Used with TASK_QUEUE_TYPE_NEXUS and polled via PollNexusTaskQueue.
Used in: , , , , , , ,
TASK_QUEUE_TYPE_UNSPECIFIED = 0
TASK_QUEUE_TYPE_WORKFLOW = 1
Workflow type of task queue.
TASK_QUEUE_TYPE_ACTIVITY = 2
Activity type of task queue.
TASK_QUEUE_TYPE_NEXUS = 3
Task queue type for dispatching Nexus requests.
Specifies which category of tasks may reach a worker on a versioned task queue. Used both in a reachability query and its response. Deprecated.
Used in: ,
TASK_REACHABILITY_UNSPECIFIED = 0
TASK_REACHABILITY_NEW_WORKFLOWS = 1
There's a possiblity for a worker to receive new workflow tasks. Workers should *not* be retired.
TASK_REACHABILITY_EXISTING_WORKFLOWS = 2
There's a possiblity for a worker to receive existing workflow and activity tasks from existing workflows. Workers should *not* be retired. This enum value does not distinguish between open and closed workflows.
TASK_REACHABILITY_OPEN_WORKFLOWS = 3
There's a possiblity for a worker to receive existing workflow and activity tasks from open workflows. Workers should *not* be retired.
TASK_REACHABILITY_CLOSED_WORKFLOWS = 4
There's a possiblity for a worker to receive existing workflow tasks from closed workflows. Workers may be retired dependending on application requirements. For example, if there's no need to query closed workflows.
Used in: ,
TIMEOUT_TYPE_UNSPECIFIED = 0
TIMEOUT_TYPE_START_TO_CLOSE = 1
TIMEOUT_TYPE_SCHEDULE_TO_START = 2
TIMEOUT_TYPE_SCHEDULE_TO_CLOSE = 3
TIMEOUT_TYPE_HEARTBEAT = 4
Records why a WorkflowExecutionUpdateAdmittedEvent was written to history. Note that not all admitted Updates result in this event.
Used in:
UPDATE_ADMITTED_EVENT_ORIGIN_UNSPECIFIED = 0
UPDATE_ADMITTED_EVENT_ORIGIN_REAPPLY = 1
The UpdateAdmitted event was created when reapplying events during reset or replication. I.e. an accepted Update on one branch of Workflow history was converted into an admitted Update on a different branch.
UpdateWorkflowExecutionLifecycleStage is specified by clients invoking Workflow Updates and used to indicate to the server how long the client wishes to wait for a return value from the API. If any value other than UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_COMPLETED is sent by the client then the API will complete before the Update is finished and will return a handle to the running Update so that it can later be polled for completion. If specified stage wasn't reached before server timeout, server returns actual stage reached.
Used in: , ,
UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_UNSPECIFIED = 0
An unspecified value for this enum.
UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_ADMITTED = 1
The API call will not return until the Update request has been admitted by the server - it may be the case that due to a considerations like load or resource limits that an Update is made to wait before the server will indicate that it has been received and will be processed. This value does not wait for any sort of acknowledgement from a worker.
UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_ACCEPTED = 2
The API call will not return until the Update has passed validation on a worker.
UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_COMPLETED = 3
The API call will not return until the Update has executed to completion on a worker and has either been rejected or returned a value or an error.
(-- api-linter: core::0216::synonyms=disabled aip.dev/not-precedent: Call this status because it is . --) Specify the drainage status for a Worker Deployment Version so users can decide whether they can safely decommission the version.
Used in: ,
VERSION_DRAINAGE_STATUS_UNSPECIFIED = 0
Drainage Status is not specified.
VERSION_DRAINAGE_STATUS_DRAINING = 1
The Worker Deployment Version is not used by new workflows but is still used by open pinned workflows. The version cannot be decommissioned safely.
VERSION_DRAINAGE_STATUS_DRAINED = 2
The Worker Deployment Version is not used by new or open workflows, but might be still needed by Queries sent to closed workflows. The version can be decommissioned safely if user does not query closed workflows. If the user does query closed workflows for some time x after workflows are closed, they should decommission the version after it has been drained for that duration.
Versioning Behavior specifies if and how a workflow execution moves between Worker Deployment Versions. The Versioning Behavior of a workflow execution is typically specified by the worker who completes the first task of the execution, but is also overridable manually for new and existing workflows (see VersioningOverride).
Used in: , , ,
VERSIONING_BEHAVIOR_UNSPECIFIED = 0
Workflow execution does not have a Versioning Behavior and is called Unversioned. This is the legacy behavior. An Unversioned workflow's task can go to any Unversioned worker (see `WorkerVersioningMode`.) User needs to use Patching to keep the new code compatible with prior versions when dealing with Unversioned workflows.
VERSIONING_BEHAVIOR_PINNED = 1
Workflow will start on its Target Version and then will be pinned to that same Deployment Version until completion (the Version that this Workflow is pinned to is specified in `versioning_info.version` and is the Pinned Version of the Workflow). The workflow's Target Version is the Current Version of its Task Queue, or, if the Task Queue has a Ramping Version with non-zero Ramp Percentage `P`, the workflow's Target Version has a P% chance of being the Ramping Version. Whether a workflow falls into the Ramping group depends on its Workflow ID and and the Ramp Percentage. This behavior eliminates most of compatibility concerns users face when changing their code. Patching is not needed when pinned workflows code change. Can be overridden explicitly via `UpdateWorkflowExecutionOptions` API to move the execution to another Deployment Version. Activities of `PINNED` workflows are sent to the same Deployment Version. Exception to this would be when the activity Task Queue workers are not present in the workflow's Deployment Version, in which case the activity will be sent to the Current Deployment Version of its own task queue.
VERSIONING_BEHAVIOR_AUTO_UPGRADE = 2
Workflow will automatically move to its Target Version when the next workflow task is dispatched. The workflow's Target Version is the Current Version of its Task Queue, or, if the Task Queue has a Ramping Version with non-zero Ramp Percentage `P`, the workflow's Target Version has a P% chance of being the Ramping Version. Whether a workflow falls into the Ramping group depends on its Workflow ID and and the Ramp Percentage. AutoUpgrade behavior is suitable for long-running workflows as it allows them to move to the latest Deployment Version, but the user still needs to use Patching to keep the new code compatible with prior versions for changed workflow types. Activities of `AUTO_UPGRADE` workflows are sent to the Deployment Version of the workflow execution (as specified in versioning_info.version based on the last completed workflow task). Exception to this would be when the activity Task Queue workers are not present in the workflow's Deployment Version, in which case, the activity will be sent to a different Deployment Version according to the Current or Ramping Deployment Version of its own Task Queue. Workflows stuck on a backlogged activity will still auto-upgrade if their Target Version changes, without having to wait for the backlogged activity to complete on the old Version.
(-- api-linter: core::0216::synonyms=disabled aip.dev/not-precedent: Call this status because it is . --) Specify the status of a Worker Deployment Version.
Used in: ,
WORKER_DEPLOYMENT_VERSION_STATUS_UNSPECIFIED = 0
WORKER_DEPLOYMENT_VERSION_STATUS_INACTIVE = 1
The Worker Deployment Version has been created inside the Worker Deployment but is not used by any workflow executions. These Versions can still have workflows if they have an explicit Versioning Override targeting this Version. Such Versioning Override could be set at workflow start time, or at a later time via `UpdateWorkflowExecutionOptions`.
WORKER_DEPLOYMENT_VERSION_STATUS_CURRENT = 2
The Worker Deployment Version is the current version of the Worker Deployment. All new workflow executions and tasks of existing unversioned or AutoUpgrade workflows are routed to this version.
WORKER_DEPLOYMENT_VERSION_STATUS_RAMPING = 3
The Worker Deployment Version is the ramping version of the Worker Deployment. A subset of new Pinned workflow executions are routed to this version. Moreover, a portion of existing unversioned or AutoUpgrade workflow executions are also routed to this version.
WORKER_DEPLOYMENT_VERSION_STATUS_DRAINING = 4
The Worker Deployment Version is not used by new workflows but is still used by open pinned workflows. The version cannot be decommissioned safely.
WORKER_DEPLOYMENT_VERSION_STATUS_DRAINED = 5
The Worker Deployment Version is not used by new or open workflows, but might be still needed by Queries sent to closed workflows. The version can be decommissioned safely if user does not query closed workflows. If the user does query closed workflows for some time x after workflows are closed, they should decommission the version after it has been drained for that duration.
WORKER_DEPLOYMENT_VERSION_STATUS_CREATED = 6
The Worker Deployment Version is created by user (via `CreateWorkerDeploymentVersion` API) but server has not seen any poller for it yet.
(-- api-linter: core::0216::synonyms=disabled aip.dev/not-precedent: It seems we have both state and status, and status is a better fit for workers. --)
Used in: ,
WORKER_STATUS_UNSPECIFIED = 0
WORKER_STATUS_RUNNING = 1
WORKER_STATUS_SHUTTING_DOWN = 2
WORKER_STATUS_SHUTDOWN = 3
Versioning Mode of a worker is set by the app developer in the worker code, and specifies the behavior of the system in the following related aspects: - Whether or not Temporal Server considers this worker's version (Build ID) when dispatching tasks to it. - Whether or not the workflows processed by this worker are versioned using the worker's version.
Used in:
WORKER_VERSIONING_MODE_UNSPECIFIED = 0
WORKER_VERSIONING_MODE_UNVERSIONED = 1
Workers with this mode are not distinguished from each other for task routing, even if they have different Build IDs. Workflows processed by this worker will be unversioned and user needs to use Patching to keep the new code compatible with prior versions. This mode is recommended to be used along with Rolling Upgrade deployment strategies. Workers with this mode are represented by the special string `__unversioned__` in the APIs.
WORKER_VERSIONING_MODE_VERSIONED = 2
Workers with this mode are part of a Worker Deployment Version which is identified as "<deployment_name>.<build_id>". Such workers are called "versioned" as opposed to "unversioned". Each Deployment Version is distinguished from other Versions for task routing and users can configure Temporal Server to send tasks to a particular Version (see `WorkerDeploymentInfo.routing_config`). This mode is the best option for Blue/Green and Rainbow strategies (but typically not suitable for Rolling upgrades.) Workflow Versioning Behaviors are enabled in this mode: each workflow type must choose between the Pinned and AutoUpgrade behaviors. Depending on the chosen behavior, the user may or may not need to use Patching to keep the new code compatible with prior versions. (see VersioningBehavior enum.)
(-- api-linter: core::0216::synonyms=disabled aip.dev/not-precedent: There is WorkflowExecutionState already in another package. --)
Used in: , , , ,
WORKFLOW_EXECUTION_STATUS_UNSPECIFIED = 0
WORKFLOW_EXECUTION_STATUS_RUNNING = 1
Value 1 is hardcoded in SQL persistence.
WORKFLOW_EXECUTION_STATUS_COMPLETED = 2
WORKFLOW_EXECUTION_STATUS_FAILED = 3
WORKFLOW_EXECUTION_STATUS_CANCELED = 4
WORKFLOW_EXECUTION_STATUS_TERMINATED = 5
WORKFLOW_EXECUTION_STATUS_CONTINUED_AS_NEW = 6
WORKFLOW_EXECUTION_STATUS_TIMED_OUT = 7
WORKFLOW_EXECUTION_STATUS_PAUSED = 8
Defines what to do when trying to start a workflow with the same workflow id as a *running* workflow. Note that it is *never* valid to have two actively running instances of the same workflow id. See `WorkflowIdReusePolicy` for handling workflow id duplication with a *closed* workflow.
Used in: ,
WORKFLOW_ID_CONFLICT_POLICY_UNSPECIFIED = 0
WORKFLOW_ID_CONFLICT_POLICY_FAIL = 1
Don't start a new workflow; instead return `WorkflowExecutionAlreadyStartedFailure`.
WORKFLOW_ID_CONFLICT_POLICY_USE_EXISTING = 2
Don't start a new workflow; instead return a workflow handle for the running workflow.
WORKFLOW_ID_CONFLICT_POLICY_TERMINATE_EXISTING = 3
Terminate the running workflow before starting a new one.
Defines whether to allow re-using a workflow id from a previously *closed* workflow. If the request is denied, the server returns a `WorkflowExecutionAlreadyStartedFailure` error. See `WorkflowIdConflictPolicy` for handling workflow id duplication with a *running* workflow.
Used in: , , , ,
WORKFLOW_ID_REUSE_POLICY_UNSPECIFIED = 0
WORKFLOW_ID_REUSE_POLICY_ALLOW_DUPLICATE = 1
Allow starting a workflow execution using the same workflow id.
WORKFLOW_ID_REUSE_POLICY_ALLOW_DUPLICATE_FAILED_ONLY = 2
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].
WORKFLOW_ID_REUSE_POLICY_REJECT_DUPLICATE = 3
Do not permit re-use of the workflow id for this workflow. Future start workflow requests could potentially change the policy, allowing re-use of the workflow id.
WORKFLOW_ID_REUSE_POLICY_TERMINATE_IF_RUNNING = 4
Terminate the current Workflow if one is already running; otherwise allow reusing the Workflow ID. When using this option, `WorkflowIdConflictPolicy` must be left unspecified. Deprecated. Instead, set `WorkflowIdReusePolicy` to `ALLOW_DUPLICATE` and `WorkflowIdConflictPolicy` to `TERMINATE_EXISTING`. Note that `WorkflowIdConflictPolicy` requires Temporal Server v1.24.0 or later.
WORKFLOW_RULE_ACTION_SCOPE_UNSPECIFIED = 0
Default value, unspecified scope.
WORKFLOW_RULE_ACTION_SCOPE_WORKFLOW = 1
The action will be applied to the entire workflow.
WORKFLOW_RULE_ACTION_SCOPE_ACTIVITY = 2
The action will be applied to a specific activity.
Workflow tasks can fail for various reasons. Note that some of these reasons can only originate from the server, and some of them can only originate from the SDK/worker.
Used in: , ,
WORKFLOW_TASK_FAILED_CAUSE_UNSPECIFIED = 0
WORKFLOW_TASK_FAILED_CAUSE_UNHANDLED_COMMAND = 1
Between starting and completing the workflow task (with a workflow completion command), some new command (like a signal) was processed into workflow history. The outstanding task will be failed with this reason, and a worker must pick up a new task.
WORKFLOW_TASK_FAILED_CAUSE_BAD_SCHEDULE_ACTIVITY_ATTRIBUTES = 2
WORKFLOW_TASK_FAILED_CAUSE_BAD_REQUEST_CANCEL_ACTIVITY_ATTRIBUTES = 3
WORKFLOW_TASK_FAILED_CAUSE_BAD_START_TIMER_ATTRIBUTES = 4
WORKFLOW_TASK_FAILED_CAUSE_BAD_CANCEL_TIMER_ATTRIBUTES = 5
WORKFLOW_TASK_FAILED_CAUSE_BAD_RECORD_MARKER_ATTRIBUTES = 6
WORKFLOW_TASK_FAILED_CAUSE_BAD_COMPLETE_WORKFLOW_EXECUTION_ATTRIBUTES = 7
WORKFLOW_TASK_FAILED_CAUSE_BAD_FAIL_WORKFLOW_EXECUTION_ATTRIBUTES = 8
WORKFLOW_TASK_FAILED_CAUSE_BAD_CANCEL_WORKFLOW_EXECUTION_ATTRIBUTES = 9
WORKFLOW_TASK_FAILED_CAUSE_BAD_REQUEST_CANCEL_EXTERNAL_WORKFLOW_EXECUTION_ATTRIBUTES = 10
WORKFLOW_TASK_FAILED_CAUSE_BAD_CONTINUE_AS_NEW_ATTRIBUTES = 11
WORKFLOW_TASK_FAILED_CAUSE_START_TIMER_DUPLICATE_ID = 12
WORKFLOW_TASK_FAILED_CAUSE_RESET_STICKY_TASK_QUEUE = 13
The worker wishes to fail the task and have the next one be generated on a normal, not sticky queue. Generally workers should prefer to use the explicit `ResetStickyTaskQueue` RPC call.
WORKFLOW_TASK_FAILED_CAUSE_WORKFLOW_WORKER_UNHANDLED_FAILURE = 14
WORKFLOW_TASK_FAILED_CAUSE_BAD_SIGNAL_WORKFLOW_EXECUTION_ATTRIBUTES = 15
WORKFLOW_TASK_FAILED_CAUSE_BAD_START_CHILD_EXECUTION_ATTRIBUTES = 16
WORKFLOW_TASK_FAILED_CAUSE_FORCE_CLOSE_COMMAND = 17
WORKFLOW_TASK_FAILED_CAUSE_FAILOVER_CLOSE_COMMAND = 18
WORKFLOW_TASK_FAILED_CAUSE_BAD_SIGNAL_INPUT_SIZE = 19
WORKFLOW_TASK_FAILED_CAUSE_RESET_WORKFLOW = 20
WORKFLOW_TASK_FAILED_CAUSE_BAD_BINARY = 21
WORKFLOW_TASK_FAILED_CAUSE_SCHEDULE_ACTIVITY_DUPLICATE_ID = 22
WORKFLOW_TASK_FAILED_CAUSE_BAD_SEARCH_ATTRIBUTES = 23
WORKFLOW_TASK_FAILED_CAUSE_NON_DETERMINISTIC_ERROR = 24
The worker encountered a mismatch while replaying history between what was expected, and what the workflow code actually did.
WORKFLOW_TASK_FAILED_CAUSE_BAD_MODIFY_WORKFLOW_PROPERTIES_ATTRIBUTES = 25
WORKFLOW_TASK_FAILED_CAUSE_PENDING_CHILD_WORKFLOWS_LIMIT_EXCEEDED = 26
We send the below error codes to users when their requests would violate a size constraint of their workflow. We do this to ensure that the state of their workflow does not become too large because that can cause severe performance degradation. You can modify the thresholds for each of these errors within your dynamic config. Spawning a new child workflow would cause this workflow to exceed its limit of pending child workflows.
WORKFLOW_TASK_FAILED_CAUSE_PENDING_ACTIVITIES_LIMIT_EXCEEDED = 27
Starting a new activity would cause this workflow to exceed its limit of pending activities that we track.
WORKFLOW_TASK_FAILED_CAUSE_PENDING_SIGNALS_LIMIT_EXCEEDED = 28
A workflow has a buffer of signals that have not yet reached their destination. We return this error when sending a new signal would exceed the capacity of this buffer.
WORKFLOW_TASK_FAILED_CAUSE_PENDING_REQUEST_CANCEL_LIMIT_EXCEEDED = 29
Similarly, we have a buffer of pending requests to cancel other workflows. We return this error when our capacity for pending cancel requests is already reached.
WORKFLOW_TASK_FAILED_CAUSE_BAD_UPDATE_WORKFLOW_EXECUTION_MESSAGE = 30
Workflow execution update message (update.Acceptance, update.Rejection, or update.Response) has wrong format, or missing required fields.
WORKFLOW_TASK_FAILED_CAUSE_UNHANDLED_UPDATE = 31
Similar to WORKFLOW_TASK_FAILED_CAUSE_UNHANDLED_COMMAND, but for updates.
WORKFLOW_TASK_FAILED_CAUSE_BAD_SCHEDULE_NEXUS_OPERATION_ATTRIBUTES = 32
A workflow task completed with an invalid ScheduleNexusOperation command.
WORKFLOW_TASK_FAILED_CAUSE_PENDING_NEXUS_OPERATIONS_LIMIT_EXCEEDED = 33
A workflow task completed requesting to schedule a Nexus Operation exceeding the server configured limit.
WORKFLOW_TASK_FAILED_CAUSE_BAD_REQUEST_CANCEL_NEXUS_OPERATION_ATTRIBUTES = 34
A workflow task completed with an invalid RequestCancelNexusOperation command.
WORKFLOW_TASK_FAILED_CAUSE_FEATURE_DISABLED = 35
A workflow task completed requesting a feature that's disabled on the server (either system wide or - typically - for the workflow's namespace). Check the workflow task failure message for more information.
WORKFLOW_TASK_FAILED_CAUSE_GRPC_MESSAGE_TOO_LARGE = 36
A workflow task failed because a grpc message was too large.
WORKFLOW_TASK_FAILED_CAUSE_PAYLOADS_TOO_LARGE = 37
A workflow task failed because payloads were too large.