Class WorkflowExecutionVersioningInfo.Builder
java.lang.Object
com.google.protobuf.AbstractMessageLite.Builder
com.google.protobuf.AbstractMessage.Builder<WorkflowExecutionVersioningInfo.Builder>
com.google.protobuf.GeneratedMessageV3.Builder<WorkflowExecutionVersioningInfo.Builder>
io.temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.Builder
- All Implemented Interfaces:
com.google.protobuf.Message.Builder,com.google.protobuf.MessageLite.Builder,com.google.protobuf.MessageLiteOrBuilder,com.google.protobuf.MessageOrBuilder,WorkflowExecutionVersioningInfoOrBuilder,Cloneable
- Enclosing class:
WorkflowExecutionVersioningInfo
public static final class WorkflowExecutionVersioningInfo.Builder
extends com.google.protobuf.GeneratedMessageV3.Builder<WorkflowExecutionVersioningInfo.Builder>
implements WorkflowExecutionVersioningInfoOrBuilder
Holds all the information about worker versioning for a particular workflow execution. Experimental. Versioning info is experimental and might change in the future.Protobuf type
temporal.api.workflow.v1.WorkflowExecutionVersioningInfo-
Method Summary
Modifier and TypeMethodDescriptionaddRepeatedField(com.google.protobuf.Descriptors.FieldDescriptor field, Object value) build()clear()Versioning behavior determines how the server should treat this execution when workers are upgraded.Experimental.Deprecated.Deprecated.The Worker Deployment Version that completed the last workflow task of this workflow execution.clearField(com.google.protobuf.Descriptors.FieldDescriptor field) clearOneof(com.google.protobuf.Descriptors.OneofDescriptor oneof) Monotonic counter reflecting the latest routing decision for this workflow execution.Deprecated.temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.version is deprecated.Present if user has set an execution-specific versioning override.When present, indicates the workflow is transitioning to a different deployment version (which may belong to the same deployment name or another).clone()Versioning behavior determines how the server should treat this execution when workers are upgraded.intVersioning behavior determines how the server should treat this execution when workers are upgraded.Experimental.intExperimental.Deprecated.temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.deployment is deprecated.Deprecated.Deprecated.Deprecated.temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.deployment_transition is deprecated.Deprecated.Deprecated.The Worker Deployment Version that completed the last workflow task of this workflow execution.The Worker Deployment Version that completed the last workflow task of this workflow execution.The Worker Deployment Version that completed the last workflow task of this workflow execution.static final com.google.protobuf.Descriptors.Descriptorcom.google.protobuf.Descriptors.DescriptorlongMonotonic counter reflecting the latest routing decision for this workflow execution.Deprecated.temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.version is deprecated.com.google.protobuf.ByteStringDeprecated.temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.version is deprecated.Present if user has set an execution-specific versioning override.Present if user has set an execution-specific versioning override.Present if user has set an execution-specific versioning override.When present, indicates the workflow is transitioning to a different deployment version (which may belong to the same deployment name or another).When present, indicates the workflow is transitioning to a different deployment version (which may belong to the same deployment name or another).When present, indicates the workflow is transitioning to a different deployment version (which may belong to the same deployment name or another).booleanDeprecated.temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.deployment is deprecated.booleanDeprecated.temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.deployment_transition is deprecated.booleanThe Worker Deployment Version that completed the last workflow task of this workflow execution.booleanPresent if user has set an execution-specific versioning override.booleanWhen present, indicates the workflow is transitioning to a different deployment version (which may belong to the same deployment name or another).protected com.google.protobuf.GeneratedMessageV3.FieldAccessorTablefinal booleanmergeDeployment(Deployment value) Deprecated.Deprecated.The Worker Deployment Version that completed the last workflow task of this workflow execution.mergeFrom(com.google.protobuf.CodedInputStream input, com.google.protobuf.ExtensionRegistryLite extensionRegistry) mergeFrom(com.google.protobuf.Message other) mergeUnknownFields(com.google.protobuf.UnknownFieldSet unknownFields) Present if user has set an execution-specific versioning override.When present, indicates the workflow is transitioning to a different deployment version (which may belong to the same deployment name or another).setBehavior(VersioningBehavior value) Versioning behavior determines how the server should treat this execution when workers are upgraded.setBehaviorValue(int value) Versioning behavior determines how the server should treat this execution when workers are upgraded.Experimental.Experimental.setDeployment(Deployment value) Deprecated.setDeployment(Deployment.Builder builderForValue) Deprecated.Deprecated.setDeploymentTransition(DeploymentTransition.Builder builderForValue) Deprecated.The Worker Deployment Version that completed the last workflow task of this workflow execution.setDeploymentVersion(WorkerDeploymentVersion.Builder builderForValue) The Worker Deployment Version that completed the last workflow task of this workflow execution.setRepeatedField(com.google.protobuf.Descriptors.FieldDescriptor field, int index, Object value) setRevisionNumber(long value) Monotonic counter reflecting the latest routing decision for this workflow execution.setUnknownFields(com.google.protobuf.UnknownFieldSet unknownFields) setVersion(String value) Deprecated.temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.version is deprecated.setVersionBytes(com.google.protobuf.ByteString value) Deprecated.temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.version is deprecated.Present if user has set an execution-specific versioning override.setVersioningOverride(VersioningOverride.Builder builderForValue) Present if user has set an execution-specific versioning override.When present, indicates the workflow is transitioning to a different deployment version (which may belong to the same deployment name or another).setVersionTransition(DeploymentVersionTransition.Builder builderForValue) When present, indicates the workflow is transitioning to a different deployment version (which may belong to the same deployment name or another).Methods inherited from class com.google.protobuf.GeneratedMessageV3.Builder
getAllFields, getField, getFieldBuilder, getOneofFieldDescriptor, getParentForChildren, getRepeatedField, getRepeatedFieldBuilder, getRepeatedFieldCount, getUnknownFields, getUnknownFieldSetBuilder, hasField, hasOneof, internalGetMapField, internalGetMapFieldReflection, internalGetMutableMapField, internalGetMutableMapFieldReflection, isClean, markClean, mergeUnknownLengthDelimitedField, mergeUnknownVarintField, newBuilderForField, onBuilt, onChanged, parseUnknownField, setUnknownFieldSetBuilder, setUnknownFieldsProto3Methods inherited from class com.google.protobuf.AbstractMessage.Builder
findInitializationErrors, getInitializationErrorString, internalMergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, newUninitializedMessageException, toStringMethods inherited from class com.google.protobuf.AbstractMessageLite.Builder
addAll, addAll, mergeDelimitedFrom, mergeDelimitedFrom, mergeFrom, newUninitializedMessageExceptionMethods inherited from class java.lang.Object
equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, waitMethods inherited from interface com.google.protobuf.Message.Builder
mergeDelimitedFrom, mergeDelimitedFromMethods inherited from interface com.google.protobuf.MessageLite.Builder
mergeFromMethods inherited from interface com.google.protobuf.MessageOrBuilder
findInitializationErrors, getAllFields, getField, getInitializationErrorString, getOneofFieldDescriptor, getRepeatedField, getRepeatedFieldCount, getUnknownFields, hasField, hasOneof
-
Method Details
-
getDescriptor
public static final com.google.protobuf.Descriptors.Descriptor getDescriptor() -
internalGetFieldAccessorTable
protected com.google.protobuf.GeneratedMessageV3.FieldAccessorTable internalGetFieldAccessorTable()- Specified by:
internalGetFieldAccessorTablein classcom.google.protobuf.GeneratedMessageV3.Builder<WorkflowExecutionVersioningInfo.Builder>
-
clear
- Specified by:
clearin interfacecom.google.protobuf.Message.Builder- Specified by:
clearin interfacecom.google.protobuf.MessageLite.Builder- Overrides:
clearin classcom.google.protobuf.GeneratedMessageV3.Builder<WorkflowExecutionVersioningInfo.Builder>
-
getDescriptorForType
public com.google.protobuf.Descriptors.Descriptor getDescriptorForType()- Specified by:
getDescriptorForTypein interfacecom.google.protobuf.Message.Builder- Specified by:
getDescriptorForTypein interfacecom.google.protobuf.MessageOrBuilder- Overrides:
getDescriptorForTypein classcom.google.protobuf.GeneratedMessageV3.Builder<WorkflowExecutionVersioningInfo.Builder>
-
getDefaultInstanceForType
- Specified by:
getDefaultInstanceForTypein interfacecom.google.protobuf.MessageLiteOrBuilder- Specified by:
getDefaultInstanceForTypein interfacecom.google.protobuf.MessageOrBuilder
-
build
- Specified by:
buildin interfacecom.google.protobuf.Message.Builder- Specified by:
buildin interfacecom.google.protobuf.MessageLite.Builder
-
buildPartial
- Specified by:
buildPartialin interfacecom.google.protobuf.Message.Builder- Specified by:
buildPartialin interfacecom.google.protobuf.MessageLite.Builder
-
clone
- Specified by:
clonein interfacecom.google.protobuf.Message.Builder- Specified by:
clonein interfacecom.google.protobuf.MessageLite.Builder- Overrides:
clonein classcom.google.protobuf.GeneratedMessageV3.Builder<WorkflowExecutionVersioningInfo.Builder>
-
setField
public WorkflowExecutionVersioningInfo.Builder setField(com.google.protobuf.Descriptors.FieldDescriptor field, Object value) - Specified by:
setFieldin interfacecom.google.protobuf.Message.Builder- Overrides:
setFieldin classcom.google.protobuf.GeneratedMessageV3.Builder<WorkflowExecutionVersioningInfo.Builder>
-
clearField
public WorkflowExecutionVersioningInfo.Builder clearField(com.google.protobuf.Descriptors.FieldDescriptor field) - Specified by:
clearFieldin interfacecom.google.protobuf.Message.Builder- Overrides:
clearFieldin classcom.google.protobuf.GeneratedMessageV3.Builder<WorkflowExecutionVersioningInfo.Builder>
-
clearOneof
public WorkflowExecutionVersioningInfo.Builder clearOneof(com.google.protobuf.Descriptors.OneofDescriptor oneof) - Specified by:
clearOneofin interfacecom.google.protobuf.Message.Builder- Overrides:
clearOneofin classcom.google.protobuf.GeneratedMessageV3.Builder<WorkflowExecutionVersioningInfo.Builder>
-
setRepeatedField
public WorkflowExecutionVersioningInfo.Builder setRepeatedField(com.google.protobuf.Descriptors.FieldDescriptor field, int index, Object value) - Specified by:
setRepeatedFieldin interfacecom.google.protobuf.Message.Builder- Overrides:
setRepeatedFieldin classcom.google.protobuf.GeneratedMessageV3.Builder<WorkflowExecutionVersioningInfo.Builder>
-
addRepeatedField
public WorkflowExecutionVersioningInfo.Builder addRepeatedField(com.google.protobuf.Descriptors.FieldDescriptor field, Object value) - Specified by:
addRepeatedFieldin interfacecom.google.protobuf.Message.Builder- Overrides:
addRepeatedFieldin classcom.google.protobuf.GeneratedMessageV3.Builder<WorkflowExecutionVersioningInfo.Builder>
-
mergeFrom
- Specified by:
mergeFromin interfacecom.google.protobuf.Message.Builder- Overrides:
mergeFromin classcom.google.protobuf.AbstractMessage.Builder<WorkflowExecutionVersioningInfo.Builder>
-
mergeFrom
-
isInitialized
public final boolean isInitialized()- Specified by:
isInitializedin interfacecom.google.protobuf.MessageLiteOrBuilder- Overrides:
isInitializedin classcom.google.protobuf.GeneratedMessageV3.Builder<WorkflowExecutionVersioningInfo.Builder>
-
mergeFrom
public WorkflowExecutionVersioningInfo.Builder mergeFrom(com.google.protobuf.CodedInputStream input, com.google.protobuf.ExtensionRegistryLite extensionRegistry) throws IOException - Specified by:
mergeFromin interfacecom.google.protobuf.Message.Builder- Specified by:
mergeFromin interfacecom.google.protobuf.MessageLite.Builder- Overrides:
mergeFromin classcom.google.protobuf.AbstractMessage.Builder<WorkflowExecutionVersioningInfo.Builder>- Throws:
IOException
-
getBehaviorValue
public int getBehaviorValue()Versioning behavior determines how the server should treat this execution when workers are upgraded. When present it means this workflow execution is versioned; UNSPECIFIED means unversioned. See the comments in `VersioningBehavior` enum for more info about different behaviors. Child workflows or CaN executions **inherit** their parent/previous run's effective Versioning Behavior and Version (except when the new execution runs on a task queue not belonging to the same deployment version as the parent/previous run's task queue). The first workflow task will be dispatched according to the inherited behavior (or to the current version of the task-queue's deployment in the case of AutoUpgrade.) After completion of their first workflow task the Deployment Version and Behavior of the execution will update according to configuration on the worker. Note that `behavior` is overridden by `versioning_override` if the latter is present.
.temporal.api.enums.v1.VersioningBehavior behavior = 1;- Specified by:
getBehaviorValuein interfaceWorkflowExecutionVersioningInfoOrBuilder- Returns:
- The enum numeric value on the wire for behavior.
-
setBehaviorValue
Versioning behavior determines how the server should treat this execution when workers are upgraded. When present it means this workflow execution is versioned; UNSPECIFIED means unversioned. See the comments in `VersioningBehavior` enum for more info about different behaviors. Child workflows or CaN executions **inherit** their parent/previous run's effective Versioning Behavior and Version (except when the new execution runs on a task queue not belonging to the same deployment version as the parent/previous run's task queue). The first workflow task will be dispatched according to the inherited behavior (or to the current version of the task-queue's deployment in the case of AutoUpgrade.) After completion of their first workflow task the Deployment Version and Behavior of the execution will update according to configuration on the worker. Note that `behavior` is overridden by `versioning_override` if the latter is present.
.temporal.api.enums.v1.VersioningBehavior behavior = 1;- Parameters:
value- The enum numeric value on the wire for behavior to set.- Returns:
- This builder for chaining.
-
getBehavior
Versioning behavior determines how the server should treat this execution when workers are upgraded. When present it means this workflow execution is versioned; UNSPECIFIED means unversioned. See the comments in `VersioningBehavior` enum for more info about different behaviors. Child workflows or CaN executions **inherit** their parent/previous run's effective Versioning Behavior and Version (except when the new execution runs on a task queue not belonging to the same deployment version as the parent/previous run's task queue). The first workflow task will be dispatched according to the inherited behavior (or to the current version of the task-queue's deployment in the case of AutoUpgrade.) After completion of their first workflow task the Deployment Version and Behavior of the execution will update according to configuration on the worker. Note that `behavior` is overridden by `versioning_override` if the latter is present.
.temporal.api.enums.v1.VersioningBehavior behavior = 1;- Specified by:
getBehaviorin interfaceWorkflowExecutionVersioningInfoOrBuilder- Returns:
- The behavior.
-
setBehavior
Versioning behavior determines how the server should treat this execution when workers are upgraded. When present it means this workflow execution is versioned; UNSPECIFIED means unversioned. See the comments in `VersioningBehavior` enum for more info about different behaviors. Child workflows or CaN executions **inherit** their parent/previous run's effective Versioning Behavior and Version (except when the new execution runs on a task queue not belonging to the same deployment version as the parent/previous run's task queue). The first workflow task will be dispatched according to the inherited behavior (or to the current version of the task-queue's deployment in the case of AutoUpgrade.) After completion of their first workflow task the Deployment Version and Behavior of the execution will update according to configuration on the worker. Note that `behavior` is overridden by `versioning_override` if the latter is present.
.temporal.api.enums.v1.VersioningBehavior behavior = 1;- Parameters:
value- The behavior to set.- Returns:
- This builder for chaining.
-
clearBehavior
Versioning behavior determines how the server should treat this execution when workers are upgraded. When present it means this workflow execution is versioned; UNSPECIFIED means unversioned. See the comments in `VersioningBehavior` enum for more info about different behaviors. Child workflows or CaN executions **inherit** their parent/previous run's effective Versioning Behavior and Version (except when the new execution runs on a task queue not belonging to the same deployment version as the parent/previous run's task queue). The first workflow task will be dispatched according to the inherited behavior (or to the current version of the task-queue's deployment in the case of AutoUpgrade.) After completion of their first workflow task the Deployment Version and Behavior of the execution will update according to configuration on the worker. Note that `behavior` is overridden by `versioning_override` if the latter is present.
.temporal.api.enums.v1.VersioningBehavior behavior = 1;- Returns:
- This builder for chaining.
-
hasDeployment
Deprecated.temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.deployment is deprecated. See temporal/api/workflow/v1/message.proto;l=162The worker deployment that completed the last workflow task of this workflow execution. Must be present if `behavior` is set. Absent value means no workflow task is completed, or the last workflow task was completed by an unversioned worker. Unversioned workers may still send a deployment value which will be stored here, so the right way to check if an execution is versioned if an execution is versioned or not is via the `behavior` field. Note that `deployment` is overridden by `versioning_override` if the latter is present. Deprecated. Use `deployment_version`.
.temporal.api.deployment.v1.Deployment deployment = 2 [deprecated = true];- Specified by:
hasDeploymentin interfaceWorkflowExecutionVersioningInfoOrBuilder- Returns:
- Whether the deployment field is set.
-
getDeployment
Deprecated.temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.deployment is deprecated. See temporal/api/workflow/v1/message.proto;l=162The worker deployment that completed the last workflow task of this workflow execution. Must be present if `behavior` is set. Absent value means no workflow task is completed, or the last workflow task was completed by an unversioned worker. Unversioned workers may still send a deployment value which will be stored here, so the right way to check if an execution is versioned if an execution is versioned or not is via the `behavior` field. Note that `deployment` is overridden by `versioning_override` if the latter is present. Deprecated. Use `deployment_version`.
.temporal.api.deployment.v1.Deployment deployment = 2 [deprecated = true];- Specified by:
getDeploymentin interfaceWorkflowExecutionVersioningInfoOrBuilder- Returns:
- The deployment.
-
setDeployment
Deprecated.The worker deployment that completed the last workflow task of this workflow execution. Must be present if `behavior` is set. Absent value means no workflow task is completed, or the last workflow task was completed by an unversioned worker. Unversioned workers may still send a deployment value which will be stored here, so the right way to check if an execution is versioned if an execution is versioned or not is via the `behavior` field. Note that `deployment` is overridden by `versioning_override` if the latter is present. Deprecated. Use `deployment_version`.
.temporal.api.deployment.v1.Deployment deployment = 2 [deprecated = true]; -
setDeployment
@Deprecated public WorkflowExecutionVersioningInfo.Builder setDeployment(Deployment.Builder builderForValue) Deprecated.The worker deployment that completed the last workflow task of this workflow execution. Must be present if `behavior` is set. Absent value means no workflow task is completed, or the last workflow task was completed by an unversioned worker. Unversioned workers may still send a deployment value which will be stored here, so the right way to check if an execution is versioned if an execution is versioned or not is via the `behavior` field. Note that `deployment` is overridden by `versioning_override` if the latter is present. Deprecated. Use `deployment_version`.
.temporal.api.deployment.v1.Deployment deployment = 2 [deprecated = true]; -
mergeDeployment
Deprecated.The worker deployment that completed the last workflow task of this workflow execution. Must be present if `behavior` is set. Absent value means no workflow task is completed, or the last workflow task was completed by an unversioned worker. Unversioned workers may still send a deployment value which will be stored here, so the right way to check if an execution is versioned if an execution is versioned or not is via the `behavior` field. Note that `deployment` is overridden by `versioning_override` if the latter is present. Deprecated. Use `deployment_version`.
.temporal.api.deployment.v1.Deployment deployment = 2 [deprecated = true]; -
clearDeployment
Deprecated.The worker deployment that completed the last workflow task of this workflow execution. Must be present if `behavior` is set. Absent value means no workflow task is completed, or the last workflow task was completed by an unversioned worker. Unversioned workers may still send a deployment value which will be stored here, so the right way to check if an execution is versioned if an execution is versioned or not is via the `behavior` field. Note that `deployment` is overridden by `versioning_override` if the latter is present. Deprecated. Use `deployment_version`.
.temporal.api.deployment.v1.Deployment deployment = 2 [deprecated = true]; -
getDeploymentBuilder
Deprecated.The worker deployment that completed the last workflow task of this workflow execution. Must be present if `behavior` is set. Absent value means no workflow task is completed, or the last workflow task was completed by an unversioned worker. Unversioned workers may still send a deployment value which will be stored here, so the right way to check if an execution is versioned if an execution is versioned or not is via the `behavior` field. Note that `deployment` is overridden by `versioning_override` if the latter is present. Deprecated. Use `deployment_version`.
.temporal.api.deployment.v1.Deployment deployment = 2 [deprecated = true]; -
getDeploymentOrBuilder
Deprecated.The worker deployment that completed the last workflow task of this workflow execution. Must be present if `behavior` is set. Absent value means no workflow task is completed, or the last workflow task was completed by an unversioned worker. Unversioned workers may still send a deployment value which will be stored here, so the right way to check if an execution is versioned if an execution is versioned or not is via the `behavior` field. Note that `deployment` is overridden by `versioning_override` if the latter is present. Deprecated. Use `deployment_version`.
.temporal.api.deployment.v1.Deployment deployment = 2 [deprecated = true];- Specified by:
getDeploymentOrBuilderin interfaceWorkflowExecutionVersioningInfoOrBuilder
-
getVersion
Deprecated.temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.version is deprecated. See temporal/api/workflow/v1/message.proto;l=164Deprecated. Use `deployment_version`.
string version = 5 [deprecated = true];- Specified by:
getVersionin interfaceWorkflowExecutionVersioningInfoOrBuilder- Returns:
- The version.
-
getVersionBytes
Deprecated.temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.version is deprecated. See temporal/api/workflow/v1/message.proto;l=164Deprecated. Use `deployment_version`.
string version = 5 [deprecated = true];- Specified by:
getVersionBytesin interfaceWorkflowExecutionVersioningInfoOrBuilder- Returns:
- The bytes for version.
-
setVersion
Deprecated.temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.version is deprecated. See temporal/api/workflow/v1/message.proto;l=164Deprecated. Use `deployment_version`.
string version = 5 [deprecated = true];- Parameters:
value- The version to set.- Returns:
- This builder for chaining.
-
clearVersion
Deprecated.temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.version is deprecated. See temporal/api/workflow/v1/message.proto;l=164Deprecated. Use `deployment_version`.
string version = 5 [deprecated = true];- Returns:
- This builder for chaining.
-
setVersionBytes
@Deprecated public WorkflowExecutionVersioningInfo.Builder setVersionBytes(com.google.protobuf.ByteString value) Deprecated.temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.version is deprecated. See temporal/api/workflow/v1/message.proto;l=164Deprecated. Use `deployment_version`.
string version = 5 [deprecated = true];- Parameters:
value- The bytes for version to set.- Returns:
- This builder for chaining.
-
hasDeploymentVersion
public boolean hasDeploymentVersion()The Worker Deployment Version that completed the last workflow task of this workflow execution. An absent value means no workflow task is completed, or the workflow is unversioned. If present, and `behavior` is UNSPECIFIED, the last task of this workflow execution was completed by a worker that is not using versioning but _is_ passing Deployment Name and Build ID. Child workflows or CaN executions **inherit** their parent/previous run's effective Versioning Behavior and Version (except when the new execution runs on a task queue not belonging to the same deployment version as the parent/previous run's task queue). The first workflow task will be dispatched according to the inherited behavior (or to the current version of the task-queue's deployment in the case of AutoUpgrade.) After completion of their first workflow task the Deployment Version and Behavior of the execution will update according to configuration on the worker. Note that if `versioning_override.behavior` is PINNED then `versioning_override.pinned_version` will override this value.
.temporal.api.deployment.v1.WorkerDeploymentVersion deployment_version = 7;- Specified by:
hasDeploymentVersionin interfaceWorkflowExecutionVersioningInfoOrBuilder- Returns:
- Whether the deploymentVersion field is set.
-
getDeploymentVersion
The Worker Deployment Version that completed the last workflow task of this workflow execution. An absent value means no workflow task is completed, or the workflow is unversioned. If present, and `behavior` is UNSPECIFIED, the last task of this workflow execution was completed by a worker that is not using versioning but _is_ passing Deployment Name and Build ID. Child workflows or CaN executions **inherit** their parent/previous run's effective Versioning Behavior and Version (except when the new execution runs on a task queue not belonging to the same deployment version as the parent/previous run's task queue). The first workflow task will be dispatched according to the inherited behavior (or to the current version of the task-queue's deployment in the case of AutoUpgrade.) After completion of their first workflow task the Deployment Version and Behavior of the execution will update according to configuration on the worker. Note that if `versioning_override.behavior` is PINNED then `versioning_override.pinned_version` will override this value.
.temporal.api.deployment.v1.WorkerDeploymentVersion deployment_version = 7;- Specified by:
getDeploymentVersionin interfaceWorkflowExecutionVersioningInfoOrBuilder- Returns:
- The deploymentVersion.
-
setDeploymentVersion
The Worker Deployment Version that completed the last workflow task of this workflow execution. An absent value means no workflow task is completed, or the workflow is unversioned. If present, and `behavior` is UNSPECIFIED, the last task of this workflow execution was completed by a worker that is not using versioning but _is_ passing Deployment Name and Build ID. Child workflows or CaN executions **inherit** their parent/previous run's effective Versioning Behavior and Version (except when the new execution runs on a task queue not belonging to the same deployment version as the parent/previous run's task queue). The first workflow task will be dispatched according to the inherited behavior (or to the current version of the task-queue's deployment in the case of AutoUpgrade.) After completion of their first workflow task the Deployment Version and Behavior of the execution will update according to configuration on the worker. Note that if `versioning_override.behavior` is PINNED then `versioning_override.pinned_version` will override this value.
.temporal.api.deployment.v1.WorkerDeploymentVersion deployment_version = 7; -
setDeploymentVersion
public WorkflowExecutionVersioningInfo.Builder setDeploymentVersion(WorkerDeploymentVersion.Builder builderForValue) The Worker Deployment Version that completed the last workflow task of this workflow execution. An absent value means no workflow task is completed, or the workflow is unversioned. If present, and `behavior` is UNSPECIFIED, the last task of this workflow execution was completed by a worker that is not using versioning but _is_ passing Deployment Name and Build ID. Child workflows or CaN executions **inherit** their parent/previous run's effective Versioning Behavior and Version (except when the new execution runs on a task queue not belonging to the same deployment version as the parent/previous run's task queue). The first workflow task will be dispatched according to the inherited behavior (or to the current version of the task-queue's deployment in the case of AutoUpgrade.) After completion of their first workflow task the Deployment Version and Behavior of the execution will update according to configuration on the worker. Note that if `versioning_override.behavior` is PINNED then `versioning_override.pinned_version` will override this value.
.temporal.api.deployment.v1.WorkerDeploymentVersion deployment_version = 7; -
mergeDeploymentVersion
public WorkflowExecutionVersioningInfo.Builder mergeDeploymentVersion(WorkerDeploymentVersion value) The Worker Deployment Version that completed the last workflow task of this workflow execution. An absent value means no workflow task is completed, or the workflow is unversioned. If present, and `behavior` is UNSPECIFIED, the last task of this workflow execution was completed by a worker that is not using versioning but _is_ passing Deployment Name and Build ID. Child workflows or CaN executions **inherit** their parent/previous run's effective Versioning Behavior and Version (except when the new execution runs on a task queue not belonging to the same deployment version as the parent/previous run's task queue). The first workflow task will be dispatched according to the inherited behavior (or to the current version of the task-queue's deployment in the case of AutoUpgrade.) After completion of their first workflow task the Deployment Version and Behavior of the execution will update according to configuration on the worker. Note that if `versioning_override.behavior` is PINNED then `versioning_override.pinned_version` will override this value.
.temporal.api.deployment.v1.WorkerDeploymentVersion deployment_version = 7; -
clearDeploymentVersion
The Worker Deployment Version that completed the last workflow task of this workflow execution. An absent value means no workflow task is completed, or the workflow is unversioned. If present, and `behavior` is UNSPECIFIED, the last task of this workflow execution was completed by a worker that is not using versioning but _is_ passing Deployment Name and Build ID. Child workflows or CaN executions **inherit** their parent/previous run's effective Versioning Behavior and Version (except when the new execution runs on a task queue not belonging to the same deployment version as the parent/previous run's task queue). The first workflow task will be dispatched according to the inherited behavior (or to the current version of the task-queue's deployment in the case of AutoUpgrade.) After completion of their first workflow task the Deployment Version and Behavior of the execution will update according to configuration on the worker. Note that if `versioning_override.behavior` is PINNED then `versioning_override.pinned_version` will override this value.
.temporal.api.deployment.v1.WorkerDeploymentVersion deployment_version = 7; -
getDeploymentVersionBuilder
The Worker Deployment Version that completed the last workflow task of this workflow execution. An absent value means no workflow task is completed, or the workflow is unversioned. If present, and `behavior` is UNSPECIFIED, the last task of this workflow execution was completed by a worker that is not using versioning but _is_ passing Deployment Name and Build ID. Child workflows or CaN executions **inherit** their parent/previous run's effective Versioning Behavior and Version (except when the new execution runs on a task queue not belonging to the same deployment version as the parent/previous run's task queue). The first workflow task will be dispatched according to the inherited behavior (or to the current version of the task-queue's deployment in the case of AutoUpgrade.) After completion of their first workflow task the Deployment Version and Behavior of the execution will update according to configuration on the worker. Note that if `versioning_override.behavior` is PINNED then `versioning_override.pinned_version` will override this value.
.temporal.api.deployment.v1.WorkerDeploymentVersion deployment_version = 7; -
getDeploymentVersionOrBuilder
The Worker Deployment Version that completed the last workflow task of this workflow execution. An absent value means no workflow task is completed, or the workflow is unversioned. If present, and `behavior` is UNSPECIFIED, the last task of this workflow execution was completed by a worker that is not using versioning but _is_ passing Deployment Name and Build ID. Child workflows or CaN executions **inherit** their parent/previous run's effective Versioning Behavior and Version (except when the new execution runs on a task queue not belonging to the same deployment version as the parent/previous run's task queue). The first workflow task will be dispatched according to the inherited behavior (or to the current version of the task-queue's deployment in the case of AutoUpgrade.) After completion of their first workflow task the Deployment Version and Behavior of the execution will update according to configuration on the worker. Note that if `versioning_override.behavior` is PINNED then `versioning_override.pinned_version` will override this value.
.temporal.api.deployment.v1.WorkerDeploymentVersion deployment_version = 7;- Specified by:
getDeploymentVersionOrBuilderin interfaceWorkflowExecutionVersioningInfoOrBuilder
-
hasVersioningOverride
public boolean hasVersioningOverride()Present if user has set an execution-specific versioning override. This override takes precedence over SDK-sent `behavior` (and `version` when override is PINNED). An override can be set when starting a new execution, as well as afterwards by calling the `UpdateWorkflowExecutionOptions` API. Pinned overrides are automatically inherited by child workflows, continue-as-new workflows, workflow retries, and cron workflows.
.temporal.api.workflow.v1.VersioningOverride versioning_override = 3;- Specified by:
hasVersioningOverridein interfaceWorkflowExecutionVersioningInfoOrBuilder- Returns:
- Whether the versioningOverride field is set.
-
getVersioningOverride
Present if user has set an execution-specific versioning override. This override takes precedence over SDK-sent `behavior` (and `version` when override is PINNED). An override can be set when starting a new execution, as well as afterwards by calling the `UpdateWorkflowExecutionOptions` API. Pinned overrides are automatically inherited by child workflows, continue-as-new workflows, workflow retries, and cron workflows.
.temporal.api.workflow.v1.VersioningOverride versioning_override = 3;- Specified by:
getVersioningOverridein interfaceWorkflowExecutionVersioningInfoOrBuilder- Returns:
- The versioningOverride.
-
setVersioningOverride
Present if user has set an execution-specific versioning override. This override takes precedence over SDK-sent `behavior` (and `version` when override is PINNED). An override can be set when starting a new execution, as well as afterwards by calling the `UpdateWorkflowExecutionOptions` API. Pinned overrides are automatically inherited by child workflows, continue-as-new workflows, workflow retries, and cron workflows.
.temporal.api.workflow.v1.VersioningOverride versioning_override = 3; -
setVersioningOverride
public WorkflowExecutionVersioningInfo.Builder setVersioningOverride(VersioningOverride.Builder builderForValue) Present if user has set an execution-specific versioning override. This override takes precedence over SDK-sent `behavior` (and `version` when override is PINNED). An override can be set when starting a new execution, as well as afterwards by calling the `UpdateWorkflowExecutionOptions` API. Pinned overrides are automatically inherited by child workflows, continue-as-new workflows, workflow retries, and cron workflows.
.temporal.api.workflow.v1.VersioningOverride versioning_override = 3; -
mergeVersioningOverride
Present if user has set an execution-specific versioning override. This override takes precedence over SDK-sent `behavior` (and `version` when override is PINNED). An override can be set when starting a new execution, as well as afterwards by calling the `UpdateWorkflowExecutionOptions` API. Pinned overrides are automatically inherited by child workflows, continue-as-new workflows, workflow retries, and cron workflows.
.temporal.api.workflow.v1.VersioningOverride versioning_override = 3; -
clearVersioningOverride
Present if user has set an execution-specific versioning override. This override takes precedence over SDK-sent `behavior` (and `version` when override is PINNED). An override can be set when starting a new execution, as well as afterwards by calling the `UpdateWorkflowExecutionOptions` API. Pinned overrides are automatically inherited by child workflows, continue-as-new workflows, workflow retries, and cron workflows.
.temporal.api.workflow.v1.VersioningOverride versioning_override = 3; -
getVersioningOverrideBuilder
Present if user has set an execution-specific versioning override. This override takes precedence over SDK-sent `behavior` (and `version` when override is PINNED). An override can be set when starting a new execution, as well as afterwards by calling the `UpdateWorkflowExecutionOptions` API. Pinned overrides are automatically inherited by child workflows, continue-as-new workflows, workflow retries, and cron workflows.
.temporal.api.workflow.v1.VersioningOverride versioning_override = 3; -
getVersioningOverrideOrBuilder
Present if user has set an execution-specific versioning override. This override takes precedence over SDK-sent `behavior` (and `version` when override is PINNED). An override can be set when starting a new execution, as well as afterwards by calling the `UpdateWorkflowExecutionOptions` API. Pinned overrides are automatically inherited by child workflows, continue-as-new workflows, workflow retries, and cron workflows.
.temporal.api.workflow.v1.VersioningOverride versioning_override = 3;- Specified by:
getVersioningOverrideOrBuilderin interfaceWorkflowExecutionVersioningInfoOrBuilder
-
hasDeploymentTransition
Deprecated.temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.deployment_transition is deprecated. See temporal/api/workflow/v1/message.proto;l=205When present, indicates the workflow is transitioning to a different deployment. Can indicate one of the following transitions: unversioned -> versioned, versioned -> versioned on a different deployment, or versioned -> unversioned. Not applicable to workflows with PINNED behavior. When a workflow with AUTO_UPGRADE behavior creates a new workflow task, it will automatically start a transition to the task queue's current deployment if the task queue's current deployment is different from the workflow's deployment. If the AUTO_UPGRADE workflow is stuck due to backlogged activity or workflow tasks, those tasks will be redirected to the task queue's current deployment. As soon as a poller from that deployment is available to receive the task, the workflow will automatically start a transition to that deployment and continue execution there. A deployment transition can only exist while there is a pending or started workflow task. Once the pending workflow task completes on the transition's target deployment, the transition completes and the workflow's `deployment` and `behavior` fields are updated per the worker's task completion response. Pending activities will not start new attempts during a transition. Once the transition is completed, pending activities will start their next attempt on the new deployment. Deprecated. Use version_transition.
.temporal.api.workflow.v1.DeploymentTransition deployment_transition = 4 [deprecated = true];- Specified by:
hasDeploymentTransitionin interfaceWorkflowExecutionVersioningInfoOrBuilder- Returns:
- Whether the deploymentTransition field is set.
-
getDeploymentTransition
Deprecated.temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.deployment_transition is deprecated. See temporal/api/workflow/v1/message.proto;l=205When present, indicates the workflow is transitioning to a different deployment. Can indicate one of the following transitions: unversioned -> versioned, versioned -> versioned on a different deployment, or versioned -> unversioned. Not applicable to workflows with PINNED behavior. When a workflow with AUTO_UPGRADE behavior creates a new workflow task, it will automatically start a transition to the task queue's current deployment if the task queue's current deployment is different from the workflow's deployment. If the AUTO_UPGRADE workflow is stuck due to backlogged activity or workflow tasks, those tasks will be redirected to the task queue's current deployment. As soon as a poller from that deployment is available to receive the task, the workflow will automatically start a transition to that deployment and continue execution there. A deployment transition can only exist while there is a pending or started workflow task. Once the pending workflow task completes on the transition's target deployment, the transition completes and the workflow's `deployment` and `behavior` fields are updated per the worker's task completion response. Pending activities will not start new attempts during a transition. Once the transition is completed, pending activities will start their next attempt on the new deployment. Deprecated. Use version_transition.
.temporal.api.workflow.v1.DeploymentTransition deployment_transition = 4 [deprecated = true];- Specified by:
getDeploymentTransitionin interfaceWorkflowExecutionVersioningInfoOrBuilder- Returns:
- The deploymentTransition.
-
setDeploymentTransition
@Deprecated public WorkflowExecutionVersioningInfo.Builder setDeploymentTransition(DeploymentTransition value) Deprecated.When present, indicates the workflow is transitioning to a different deployment. Can indicate one of the following transitions: unversioned -> versioned, versioned -> versioned on a different deployment, or versioned -> unversioned. Not applicable to workflows with PINNED behavior. When a workflow with AUTO_UPGRADE behavior creates a new workflow task, it will automatically start a transition to the task queue's current deployment if the task queue's current deployment is different from the workflow's deployment. If the AUTO_UPGRADE workflow is stuck due to backlogged activity or workflow tasks, those tasks will be redirected to the task queue's current deployment. As soon as a poller from that deployment is available to receive the task, the workflow will automatically start a transition to that deployment and continue execution there. A deployment transition can only exist while there is a pending or started workflow task. Once the pending workflow task completes on the transition's target deployment, the transition completes and the workflow's `deployment` and `behavior` fields are updated per the worker's task completion response. Pending activities will not start new attempts during a transition. Once the transition is completed, pending activities will start their next attempt on the new deployment. Deprecated. Use version_transition.
.temporal.api.workflow.v1.DeploymentTransition deployment_transition = 4 [deprecated = true]; -
setDeploymentTransition
@Deprecated public WorkflowExecutionVersioningInfo.Builder setDeploymentTransition(DeploymentTransition.Builder builderForValue) Deprecated.When present, indicates the workflow is transitioning to a different deployment. Can indicate one of the following transitions: unversioned -> versioned, versioned -> versioned on a different deployment, or versioned -> unversioned. Not applicable to workflows with PINNED behavior. When a workflow with AUTO_UPGRADE behavior creates a new workflow task, it will automatically start a transition to the task queue's current deployment if the task queue's current deployment is different from the workflow's deployment. If the AUTO_UPGRADE workflow is stuck due to backlogged activity or workflow tasks, those tasks will be redirected to the task queue's current deployment. As soon as a poller from that deployment is available to receive the task, the workflow will automatically start a transition to that deployment and continue execution there. A deployment transition can only exist while there is a pending or started workflow task. Once the pending workflow task completes on the transition's target deployment, the transition completes and the workflow's `deployment` and `behavior` fields are updated per the worker's task completion response. Pending activities will not start new attempts during a transition. Once the transition is completed, pending activities will start their next attempt on the new deployment. Deprecated. Use version_transition.
.temporal.api.workflow.v1.DeploymentTransition deployment_transition = 4 [deprecated = true]; -
mergeDeploymentTransition
@Deprecated public WorkflowExecutionVersioningInfo.Builder mergeDeploymentTransition(DeploymentTransition value) Deprecated.When present, indicates the workflow is transitioning to a different deployment. Can indicate one of the following transitions: unversioned -> versioned, versioned -> versioned on a different deployment, or versioned -> unversioned. Not applicable to workflows with PINNED behavior. When a workflow with AUTO_UPGRADE behavior creates a new workflow task, it will automatically start a transition to the task queue's current deployment if the task queue's current deployment is different from the workflow's deployment. If the AUTO_UPGRADE workflow is stuck due to backlogged activity or workflow tasks, those tasks will be redirected to the task queue's current deployment. As soon as a poller from that deployment is available to receive the task, the workflow will automatically start a transition to that deployment and continue execution there. A deployment transition can only exist while there is a pending or started workflow task. Once the pending workflow task completes on the transition's target deployment, the transition completes and the workflow's `deployment` and `behavior` fields are updated per the worker's task completion response. Pending activities will not start new attempts during a transition. Once the transition is completed, pending activities will start their next attempt on the new deployment. Deprecated. Use version_transition.
.temporal.api.workflow.v1.DeploymentTransition deployment_transition = 4 [deprecated = true]; -
clearDeploymentTransition
Deprecated.When present, indicates the workflow is transitioning to a different deployment. Can indicate one of the following transitions: unversioned -> versioned, versioned -> versioned on a different deployment, or versioned -> unversioned. Not applicable to workflows with PINNED behavior. When a workflow with AUTO_UPGRADE behavior creates a new workflow task, it will automatically start a transition to the task queue's current deployment if the task queue's current deployment is different from the workflow's deployment. If the AUTO_UPGRADE workflow is stuck due to backlogged activity or workflow tasks, those tasks will be redirected to the task queue's current deployment. As soon as a poller from that deployment is available to receive the task, the workflow will automatically start a transition to that deployment and continue execution there. A deployment transition can only exist while there is a pending or started workflow task. Once the pending workflow task completes on the transition's target deployment, the transition completes and the workflow's `deployment` and `behavior` fields are updated per the worker's task completion response. Pending activities will not start new attempts during a transition. Once the transition is completed, pending activities will start their next attempt on the new deployment. Deprecated. Use version_transition.
.temporal.api.workflow.v1.DeploymentTransition deployment_transition = 4 [deprecated = true]; -
getDeploymentTransitionBuilder
Deprecated.When present, indicates the workflow is transitioning to a different deployment. Can indicate one of the following transitions: unversioned -> versioned, versioned -> versioned on a different deployment, or versioned -> unversioned. Not applicable to workflows with PINNED behavior. When a workflow with AUTO_UPGRADE behavior creates a new workflow task, it will automatically start a transition to the task queue's current deployment if the task queue's current deployment is different from the workflow's deployment. If the AUTO_UPGRADE workflow is stuck due to backlogged activity or workflow tasks, those tasks will be redirected to the task queue's current deployment. As soon as a poller from that deployment is available to receive the task, the workflow will automatically start a transition to that deployment and continue execution there. A deployment transition can only exist while there is a pending or started workflow task. Once the pending workflow task completes on the transition's target deployment, the transition completes and the workflow's `deployment` and `behavior` fields are updated per the worker's task completion response. Pending activities will not start new attempts during a transition. Once the transition is completed, pending activities will start their next attempt on the new deployment. Deprecated. Use version_transition.
.temporal.api.workflow.v1.DeploymentTransition deployment_transition = 4 [deprecated = true]; -
getDeploymentTransitionOrBuilder
Deprecated.When present, indicates the workflow is transitioning to a different deployment. Can indicate one of the following transitions: unversioned -> versioned, versioned -> versioned on a different deployment, or versioned -> unversioned. Not applicable to workflows with PINNED behavior. When a workflow with AUTO_UPGRADE behavior creates a new workflow task, it will automatically start a transition to the task queue's current deployment if the task queue's current deployment is different from the workflow's deployment. If the AUTO_UPGRADE workflow is stuck due to backlogged activity or workflow tasks, those tasks will be redirected to the task queue's current deployment. As soon as a poller from that deployment is available to receive the task, the workflow will automatically start a transition to that deployment and continue execution there. A deployment transition can only exist while there is a pending or started workflow task. Once the pending workflow task completes on the transition's target deployment, the transition completes and the workflow's `deployment` and `behavior` fields are updated per the worker's task completion response. Pending activities will not start new attempts during a transition. Once the transition is completed, pending activities will start their next attempt on the new deployment. Deprecated. Use version_transition.
.temporal.api.workflow.v1.DeploymentTransition deployment_transition = 4 [deprecated = true];- Specified by:
getDeploymentTransitionOrBuilderin interfaceWorkflowExecutionVersioningInfoOrBuilder
-
hasVersionTransition
public boolean hasVersionTransition()When present, indicates the workflow is transitioning to a different deployment version (which may belong to the same deployment name or another). Can indicate one of the following transitions: unversioned -> versioned, versioned -> versioned on a different deployment version, or versioned -> unversioned. Not applicable to workflows with PINNED behavior. When a workflow with AUTO_UPGRADE behavior creates a new workflow task, it will automatically start a transition to the task queue's current version if the task queue's current version is different from the workflow's current deployment version. If the AUTO_UPGRADE workflow is stuck due to backlogged activity or workflow tasks, those tasks will be redirected to the task queue's current version. As soon as a poller from that deployment version is available to receive the task, the workflow will automatically start a transition to that version and continue execution there. A version transition can only exist while there is a pending or started workflow task. Once the pending workflow task completes on the transition's target version, the transition completes and the workflow's `behavior`, and `deployment_version` fields are updated per the worker's task completion response. Pending activities will not start new attempts during a transition. Once the transition is completed, pending activities will start their next attempt on the new version.
.temporal.api.workflow.v1.DeploymentVersionTransition version_transition = 6;- Specified by:
hasVersionTransitionin interfaceWorkflowExecutionVersioningInfoOrBuilder- Returns:
- Whether the versionTransition field is set.
-
getVersionTransition
When present, indicates the workflow is transitioning to a different deployment version (which may belong to the same deployment name or another). Can indicate one of the following transitions: unversioned -> versioned, versioned -> versioned on a different deployment version, or versioned -> unversioned. Not applicable to workflows with PINNED behavior. When a workflow with AUTO_UPGRADE behavior creates a new workflow task, it will automatically start a transition to the task queue's current version if the task queue's current version is different from the workflow's current deployment version. If the AUTO_UPGRADE workflow is stuck due to backlogged activity or workflow tasks, those tasks will be redirected to the task queue's current version. As soon as a poller from that deployment version is available to receive the task, the workflow will automatically start a transition to that version and continue execution there. A version transition can only exist while there is a pending or started workflow task. Once the pending workflow task completes on the transition's target version, the transition completes and the workflow's `behavior`, and `deployment_version` fields are updated per the worker's task completion response. Pending activities will not start new attempts during a transition. Once the transition is completed, pending activities will start their next attempt on the new version.
.temporal.api.workflow.v1.DeploymentVersionTransition version_transition = 6;- Specified by:
getVersionTransitionin interfaceWorkflowExecutionVersioningInfoOrBuilder- Returns:
- The versionTransition.
-
setVersionTransition
public WorkflowExecutionVersioningInfo.Builder setVersionTransition(DeploymentVersionTransition value) When present, indicates the workflow is transitioning to a different deployment version (which may belong to the same deployment name or another). Can indicate one of the following transitions: unversioned -> versioned, versioned -> versioned on a different deployment version, or versioned -> unversioned. Not applicable to workflows with PINNED behavior. When a workflow with AUTO_UPGRADE behavior creates a new workflow task, it will automatically start a transition to the task queue's current version if the task queue's current version is different from the workflow's current deployment version. If the AUTO_UPGRADE workflow is stuck due to backlogged activity or workflow tasks, those tasks will be redirected to the task queue's current version. As soon as a poller from that deployment version is available to receive the task, the workflow will automatically start a transition to that version and continue execution there. A version transition can only exist while there is a pending or started workflow task. Once the pending workflow task completes on the transition's target version, the transition completes and the workflow's `behavior`, and `deployment_version` fields are updated per the worker's task completion response. Pending activities will not start new attempts during a transition. Once the transition is completed, pending activities will start their next attempt on the new version.
.temporal.api.workflow.v1.DeploymentVersionTransition version_transition = 6; -
setVersionTransition
public WorkflowExecutionVersioningInfo.Builder setVersionTransition(DeploymentVersionTransition.Builder builderForValue) When present, indicates the workflow is transitioning to a different deployment version (which may belong to the same deployment name or another). Can indicate one of the following transitions: unversioned -> versioned, versioned -> versioned on a different deployment version, or versioned -> unversioned. Not applicable to workflows with PINNED behavior. When a workflow with AUTO_UPGRADE behavior creates a new workflow task, it will automatically start a transition to the task queue's current version if the task queue's current version is different from the workflow's current deployment version. If the AUTO_UPGRADE workflow is stuck due to backlogged activity or workflow tasks, those tasks will be redirected to the task queue's current version. As soon as a poller from that deployment version is available to receive the task, the workflow will automatically start a transition to that version and continue execution there. A version transition can only exist while there is a pending or started workflow task. Once the pending workflow task completes on the transition's target version, the transition completes and the workflow's `behavior`, and `deployment_version` fields are updated per the worker's task completion response. Pending activities will not start new attempts during a transition. Once the transition is completed, pending activities will start their next attempt on the new version.
.temporal.api.workflow.v1.DeploymentVersionTransition version_transition = 6; -
mergeVersionTransition
public WorkflowExecutionVersioningInfo.Builder mergeVersionTransition(DeploymentVersionTransition value) When present, indicates the workflow is transitioning to a different deployment version (which may belong to the same deployment name or another). Can indicate one of the following transitions: unversioned -> versioned, versioned -> versioned on a different deployment version, or versioned -> unversioned. Not applicable to workflows with PINNED behavior. When a workflow with AUTO_UPGRADE behavior creates a new workflow task, it will automatically start a transition to the task queue's current version if the task queue's current version is different from the workflow's current deployment version. If the AUTO_UPGRADE workflow is stuck due to backlogged activity or workflow tasks, those tasks will be redirected to the task queue's current version. As soon as a poller from that deployment version is available to receive the task, the workflow will automatically start a transition to that version and continue execution there. A version transition can only exist while there is a pending or started workflow task. Once the pending workflow task completes on the transition's target version, the transition completes and the workflow's `behavior`, and `deployment_version` fields are updated per the worker's task completion response. Pending activities will not start new attempts during a transition. Once the transition is completed, pending activities will start their next attempt on the new version.
.temporal.api.workflow.v1.DeploymentVersionTransition version_transition = 6; -
clearVersionTransition
When present, indicates the workflow is transitioning to a different deployment version (which may belong to the same deployment name or another). Can indicate one of the following transitions: unversioned -> versioned, versioned -> versioned on a different deployment version, or versioned -> unversioned. Not applicable to workflows with PINNED behavior. When a workflow with AUTO_UPGRADE behavior creates a new workflow task, it will automatically start a transition to the task queue's current version if the task queue's current version is different from the workflow's current deployment version. If the AUTO_UPGRADE workflow is stuck due to backlogged activity or workflow tasks, those tasks will be redirected to the task queue's current version. As soon as a poller from that deployment version is available to receive the task, the workflow will automatically start a transition to that version and continue execution there. A version transition can only exist while there is a pending or started workflow task. Once the pending workflow task completes on the transition's target version, the transition completes and the workflow's `behavior`, and `deployment_version` fields are updated per the worker's task completion response. Pending activities will not start new attempts during a transition. Once the transition is completed, pending activities will start their next attempt on the new version.
.temporal.api.workflow.v1.DeploymentVersionTransition version_transition = 6; -
getVersionTransitionBuilder
When present, indicates the workflow is transitioning to a different deployment version (which may belong to the same deployment name or another). Can indicate one of the following transitions: unversioned -> versioned, versioned -> versioned on a different deployment version, or versioned -> unversioned. Not applicable to workflows with PINNED behavior. When a workflow with AUTO_UPGRADE behavior creates a new workflow task, it will automatically start a transition to the task queue's current version if the task queue's current version is different from the workflow's current deployment version. If the AUTO_UPGRADE workflow is stuck due to backlogged activity or workflow tasks, those tasks will be redirected to the task queue's current version. As soon as a poller from that deployment version is available to receive the task, the workflow will automatically start a transition to that version and continue execution there. A version transition can only exist while there is a pending or started workflow task. Once the pending workflow task completes on the transition's target version, the transition completes and the workflow's `behavior`, and `deployment_version` fields are updated per the worker's task completion response. Pending activities will not start new attempts during a transition. Once the transition is completed, pending activities will start their next attempt on the new version.
.temporal.api.workflow.v1.DeploymentVersionTransition version_transition = 6; -
getVersionTransitionOrBuilder
When present, indicates the workflow is transitioning to a different deployment version (which may belong to the same deployment name or another). Can indicate one of the following transitions: unversioned -> versioned, versioned -> versioned on a different deployment version, or versioned -> unversioned. Not applicable to workflows with PINNED behavior. When a workflow with AUTO_UPGRADE behavior creates a new workflow task, it will automatically start a transition to the task queue's current version if the task queue's current version is different from the workflow's current deployment version. If the AUTO_UPGRADE workflow is stuck due to backlogged activity or workflow tasks, those tasks will be redirected to the task queue's current version. As soon as a poller from that deployment version is available to receive the task, the workflow will automatically start a transition to that version and continue execution there. A version transition can only exist while there is a pending or started workflow task. Once the pending workflow task completes on the transition's target version, the transition completes and the workflow's `behavior`, and `deployment_version` fields are updated per the worker's task completion response. Pending activities will not start new attempts during a transition. Once the transition is completed, pending activities will start their next attempt on the new version.
.temporal.api.workflow.v1.DeploymentVersionTransition version_transition = 6;- Specified by:
getVersionTransitionOrBuilderin interfaceWorkflowExecutionVersioningInfoOrBuilder
-
getRevisionNumber
public long getRevisionNumber()Monotonic counter reflecting the latest routing decision for this workflow execution. Used for staleness detection between history and matching when dispatching tasks to workers. Incremented when a workflow execution routes to a new deployment version, which happens when a worker of the new deployment version completes a workflow task. Note: Pinned tasks and sticky tasks send a value of 0 for this field since these tasks do not face the problem of inconsistent dispatching that arises from eventual consistency between task queues and their partitions.
int64 revision_number = 8;- Specified by:
getRevisionNumberin interfaceWorkflowExecutionVersioningInfoOrBuilder- Returns:
- The revisionNumber.
-
setRevisionNumber
Monotonic counter reflecting the latest routing decision for this workflow execution. Used for staleness detection between history and matching when dispatching tasks to workers. Incremented when a workflow execution routes to a new deployment version, which happens when a worker of the new deployment version completes a workflow task. Note: Pinned tasks and sticky tasks send a value of 0 for this field since these tasks do not face the problem of inconsistent dispatching that arises from eventual consistency between task queues and their partitions.
int64 revision_number = 8;- Parameters:
value- The revisionNumber to set.- Returns:
- This builder for chaining.
-
clearRevisionNumber
Monotonic counter reflecting the latest routing decision for this workflow execution. Used for staleness detection between history and matching when dispatching tasks to workers. Incremented when a workflow execution routes to a new deployment version, which happens when a worker of the new deployment version completes a workflow task. Note: Pinned tasks and sticky tasks send a value of 0 for this field since these tasks do not face the problem of inconsistent dispatching that arises from eventual consistency between task queues and their partitions.
int64 revision_number = 8;- Returns:
- This builder for chaining.
-
getContinueAsNewInitialVersioningBehaviorValue
public int getContinueAsNewInitialVersioningBehaviorValue()Experimental. If this workflow is the result of a continue-as-new, this field is set to the initial_versioning_behavior specified in that command. Only used for the initial task of this run and the initial task of any retries of this run. Not passed to children or to future continue-as-new. Note: In the first release of Upgrade-on-CaN, when the only ContinueAsNewVersioningBehavior was AutoUpgrade, a non-empty InheritedAutoUpgradeInfo meant that the workflow should start as AutoUpgrade. So for compatibility with ContinueAsNew history commands generated during that time, know that an UNSPECIFIED value here is equivalent to ContinueAsNewVersioningBehaviorAutoUpgrade if the behavior of the workflow is AutoUpgrade.
.temporal.api.enums.v1.ContinueAsNewVersioningBehavior continue_as_new_initial_versioning_behavior = 9;- Specified by:
getContinueAsNewInitialVersioningBehaviorValuein interfaceWorkflowExecutionVersioningInfoOrBuilder- Returns:
- The enum numeric value on the wire for continueAsNewInitialVersioningBehavior.
-
setContinueAsNewInitialVersioningBehaviorValue
public WorkflowExecutionVersioningInfo.Builder setContinueAsNewInitialVersioningBehaviorValue(int value) Experimental. If this workflow is the result of a continue-as-new, this field is set to the initial_versioning_behavior specified in that command. Only used for the initial task of this run and the initial task of any retries of this run. Not passed to children or to future continue-as-new. Note: In the first release of Upgrade-on-CaN, when the only ContinueAsNewVersioningBehavior was AutoUpgrade, a non-empty InheritedAutoUpgradeInfo meant that the workflow should start as AutoUpgrade. So for compatibility with ContinueAsNew history commands generated during that time, know that an UNSPECIFIED value here is equivalent to ContinueAsNewVersioningBehaviorAutoUpgrade if the behavior of the workflow is AutoUpgrade.
.temporal.api.enums.v1.ContinueAsNewVersioningBehavior continue_as_new_initial_versioning_behavior = 9;- Parameters:
value- The enum numeric value on the wire for continueAsNewInitialVersioningBehavior to set.- Returns:
- This builder for chaining.
-
getContinueAsNewInitialVersioningBehavior
Experimental. If this workflow is the result of a continue-as-new, this field is set to the initial_versioning_behavior specified in that command. Only used for the initial task of this run and the initial task of any retries of this run. Not passed to children or to future continue-as-new. Note: In the first release of Upgrade-on-CaN, when the only ContinueAsNewVersioningBehavior was AutoUpgrade, a non-empty InheritedAutoUpgradeInfo meant that the workflow should start as AutoUpgrade. So for compatibility with ContinueAsNew history commands generated during that time, know that an UNSPECIFIED value here is equivalent to ContinueAsNewVersioningBehaviorAutoUpgrade if the behavior of the workflow is AutoUpgrade.
.temporal.api.enums.v1.ContinueAsNewVersioningBehavior continue_as_new_initial_versioning_behavior = 9;- Specified by:
getContinueAsNewInitialVersioningBehaviorin interfaceWorkflowExecutionVersioningInfoOrBuilder- Returns:
- The continueAsNewInitialVersioningBehavior.
-
setContinueAsNewInitialVersioningBehavior
public WorkflowExecutionVersioningInfo.Builder setContinueAsNewInitialVersioningBehavior(ContinueAsNewVersioningBehavior value) Experimental. If this workflow is the result of a continue-as-new, this field is set to the initial_versioning_behavior specified in that command. Only used for the initial task of this run and the initial task of any retries of this run. Not passed to children or to future continue-as-new. Note: In the first release of Upgrade-on-CaN, when the only ContinueAsNewVersioningBehavior was AutoUpgrade, a non-empty InheritedAutoUpgradeInfo meant that the workflow should start as AutoUpgrade. So for compatibility with ContinueAsNew history commands generated during that time, know that an UNSPECIFIED value here is equivalent to ContinueAsNewVersioningBehaviorAutoUpgrade if the behavior of the workflow is AutoUpgrade.
.temporal.api.enums.v1.ContinueAsNewVersioningBehavior continue_as_new_initial_versioning_behavior = 9;- Parameters:
value- The continueAsNewInitialVersioningBehavior to set.- Returns:
- This builder for chaining.
-
clearContinueAsNewInitialVersioningBehavior
Experimental. If this workflow is the result of a continue-as-new, this field is set to the initial_versioning_behavior specified in that command. Only used for the initial task of this run and the initial task of any retries of this run. Not passed to children or to future continue-as-new. Note: In the first release of Upgrade-on-CaN, when the only ContinueAsNewVersioningBehavior was AutoUpgrade, a non-empty InheritedAutoUpgradeInfo meant that the workflow should start as AutoUpgrade. So for compatibility with ContinueAsNew history commands generated during that time, know that an UNSPECIFIED value here is equivalent to ContinueAsNewVersioningBehaviorAutoUpgrade if the behavior of the workflow is AutoUpgrade.
.temporal.api.enums.v1.ContinueAsNewVersioningBehavior continue_as_new_initial_versioning_behavior = 9;- Returns:
- This builder for chaining.
-
setUnknownFields
public final WorkflowExecutionVersioningInfo.Builder setUnknownFields(com.google.protobuf.UnknownFieldSet unknownFields) - Specified by:
setUnknownFieldsin interfacecom.google.protobuf.Message.Builder- Overrides:
setUnknownFieldsin classcom.google.protobuf.GeneratedMessageV3.Builder<WorkflowExecutionVersioningInfo.Builder>
-
mergeUnknownFields
public final WorkflowExecutionVersioningInfo.Builder mergeUnknownFields(com.google.protobuf.UnknownFieldSet unknownFields) - Specified by:
mergeUnknownFieldsin interfacecom.google.protobuf.Message.Builder- Overrides:
mergeUnknownFieldsin classcom.google.protobuf.GeneratedMessageV3.Builder<WorkflowExecutionVersioningInfo.Builder>
-