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
- 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
- ParentClosePolicy
Defines how child workflows will react to their parent completing
- ResetReapplyType
Reset reapplay(replay) options
- RESET_REAPPLY_TYPE_SIGNAL (default) - Signals are reapplied when workflow is reset
- RESET_REAPPLY_TYPE_NONE - nothing is reapplied
- ScheduleOverlapPolicy
ScheduleOverlapPolicy controls what happens when a workflow would be started by a schedule, and is already running.
- UpdateWorkflowExecutionLifecycleStage
UpdateWorkflowExecutionLifecycleStage is specified by clients invoking workflow execution updates and used to indicate to the server how long the client wishes to wait for a return value from the RPC. If any value other than UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_COMPLETED is sent by the client then the RPC 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.
- WorkflowExecutionStatus
(-- api-linter: core::0216::synonyms=disabled aip.dev/not-precedent: There is WorkflowExecutionState already in another package. --)
- WorkflowIdReusePolicy
Defines how new runs of a workflow with a particular ID may or may not be allowed. Note that it is never valid to have two actively running instances of the same workflow id.
- 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.