Namespace Temporalio.Api.Enums.V1
Classes
- 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
- 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.
- 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.
- 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.
- ScheduleOverlapPolicy
ScheduleOverlapPolicy controls what happens when a workflow would be started by a schedule, and is already running.
- 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.