Namespace Temporalio.Api.Enums.V1
Classes
- ActivityReflection
Holder for reflection information generated from temporal/api/enums/v1/activity.proto
- BatchOperationReflection
Holder for reflection information generated from temporal/api/enums/v1/batch_operation.proto
- CommandTypeReflection
Holder for reflection information generated from temporal/api/enums/v1/command_type.proto
- CommonReflection
Holder for reflection information generated from temporal/api/enums/v1/common.proto
- DeploymentReflection
Holder for reflection information generated from temporal/api/enums/v1/deployment.proto
- EventTypeReflection
Holder for reflection information generated from temporal/api/enums/v1/event_type.proto
- FailedCauseReflection
Holder for reflection information generated from temporal/api/enums/v1/failed_cause.proto
- NamespaceReflection
Holder for reflection information generated from temporal/api/enums/v1/namespace.proto
- NexusReflection
Holder for reflection information generated from temporal/api/enums/v1/nexus.proto
- QueryReflection
Holder for reflection information generated from temporal/api/enums/v1/query.proto
- ResetReflection
Holder for reflection information generated from temporal/api/enums/v1/reset.proto
- ScheduleReflection
Holder for reflection information generated from temporal/api/enums/v1/schedule.proto
- TaskQueueReflection
Holder for reflection information generated from temporal/api/enums/v1/task_queue.proto
- UpdateReflection
Holder for reflection information generated from temporal/api/enums/v1/update.proto
- WorkflowReflection
Holder for reflection information generated from temporal/api/enums/v1/workflow.proto
Enums
- ActivityExecutionStatus
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. --)
- ActivityIdConflictPolicy
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
ActivityIdReusePolicyfor handling activity ID duplication with a closed activity.
- ActivityIdReusePolicy
Defines whether to allow re-using an activity ID from a previously closed activity. If the request is denied, the server returns an
ActivityExecutionAlreadyStartederror.See
ActivityIdConflictPolicyfor handling ID duplication with a running activity.
- BuildIdTaskReachability
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.
- CallbackState
State of a callback.
- CommandType
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.
- ContinueAsNewVersioningBehavior
Experimental. Defines the versioning behavior to be used by the first task of a new workflow run in a continue-as-new chain.
- DeploymentReachability
Specify the reachability level for a deployment so users can decide if it is time to decommission the deployment.
- EventType
Whenever this list of events is changed do change the function shouldBufferEvent in mutableStateBuilder.go to make sure to do the correct event ordering
- NexusHandlerErrorRetryBehavior
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.
- NexusOperationCancellationState
State of a Nexus operation cancellation.
- ParentClosePolicy
Defines how child workflows will react to their parent completing
- PendingNexusOperationState
State of a pending Nexus operation.
- RateLimitSource
Source for the effective rate limit.
- ResetReapplyExcludeType
Event types to exclude when reapplying events beyond the reset point.
- ResetReapplyType
Deprecated: applications should use ResetReapplyExcludeType to specify exclusions from this set, and new event types should be added to ResetReapplyExcludeType instead of here.
- ResetType
Deprecated, see temporal.api.common.v1.ResetOptions.
- RoutingConfigUpdateState
Indicates whether a change to the Routing Config has been propagated to all relevant Task Queues and their partitions.
- ScheduleOverlapPolicy
ScheduleOverlapPolicy controls what happens when a workflow would be started by a schedule, and is already running.
- SuggestContinueAsNewReason
SuggestContinueAsNewReason specifies why SuggestContinueAsNew is true.
- TaskReachability
Specifies which category of tasks may reach a worker on a versioned task queue. Used both in a reachability query and its response. Deprecated.
- UpdateAdmittedEventOrigin
Records why a WorkflowExecutionUpdateAdmittedEvent was written to history. Note that not all admitted Updates result in this event.
- UpdateWorkflowExecutionLifecycleStage
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.
- VersionDrainageStatus
(-- 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. Experimental. Worker Deployments are experimental and might significantly change in the future.
- VersioningBehavior
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). Experimental. Worker Deployments are experimental and might significantly change in the future.
- WorkerDeploymentVersionStatus
(-- api-linter: core::0216::synonyms=disabled aip.dev/not-precedent: Call this status because it is . --) Specify the status of a Worker Deployment Version. Experimental. Worker Deployments are experimental and might significantly change in the future.
- WorkerStatus
(-- 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. --)
- WorkerVersioningMode
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. Experimental. Worker Deployments are experimental and might significantly change in the future.
- WorkflowExecutionStatus
(-- api-linter: core::0216::synonyms=disabled aip.dev/not-precedent: There is WorkflowExecutionState already in another package. --)
- WorkflowIdConflictPolicy
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
WorkflowIdReusePolicyfor handling workflow id duplication with a closed workflow.
- WorkflowIdReusePolicy
Defines whether to allow re-using a workflow id from a previously closed workflow. If the request is denied, the server returns a
WorkflowExecutionAlreadyStartedFailureerror.See
WorkflowIdConflictPolicyfor handling workflow id duplication with a running workflow.
- WorkflowTaskFailedCause
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.