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
- 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
- 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.
- 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
- 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
Event types to include when reapplying events. Deprecated: applications should use ResetReapplyExcludeType to specify exclusions from this set, and new event types should be added to ResetReapplyExcludeType instead of here.
- ResetType
Reset type options. 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.
- 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, a
WorkflowExecutionAlreadyStartedFailureis returned.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.