Package io.temporal.api.workflow.v1

Interface WorkflowExecutionVersioningInfoOrBuilder

  • All Superinterfaces:
    com.google.protobuf.MessageLiteOrBuilder, com.google.protobuf.MessageOrBuilder
    All Known Implementing Classes:
    WorkflowExecutionVersioningInfo, WorkflowExecutionVersioningInfo.Builder
    @Generated(value="protoc",
           comments="annotations:WorkflowExecutionVersioningInfoOrBuilder.java.pb.meta")
public interface WorkflowExecutionVersioningInfoOrBuilder
extends com.google.protobuf.MessageOrBuilder

    • Method Detail

      • getBehaviorValue

        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.
 This field is first set after an execution completes its first workflow task on a versioned
 worker, and set again on completion of every subsequent workflow task.
 For child workflows of Pinned parents, this will be set to Pinned (along with `version`) when
 the the child starts so that child's first workflow task goes to the same Version as the
 parent. After the first workflow task, it depends on the child workflow itself if it wants
 to stay pinned or become unpinned (according to Versioning Behavior set in the worker).
 Note that `behavior` is overridden by `versioning_override` if the latter is present.
        .temporal.api.enums.v1.VersioningBehavior behavior = 1;
        Returns:
        The enum numeric value on the wire for behavior.

      • getBehavior

        VersioningBehavior 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.
 This field is first set after an execution completes its first workflow task on a versioned
 worker, and set again on completion of every subsequent workflow task.
 For child workflows of Pinned parents, this will be set to Pinned (along with `version`) when
 the the child starts so that child's first workflow task goes to the same Version as the
 parent. After the first workflow task, it depends on the child workflow itself if it wants
 to stay pinned or become unpinned (according to Versioning Behavior set in the worker).
 Note that `behavior` is overridden by `versioning_override` if the latter is present.
        .temporal.api.enums.v1.VersioningBehavior behavior = 1;
        Returns:
        The behavior.

      • hasDeployment

        @Deprecated
boolean hasDeployment()
        Deprecated.
        temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.deployment is deprecated. See temporal/api/workflow/v1/message.proto;l=159
         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 `version`.
        .temporal.api.deployment.v1.Deployment deployment = 2 [deprecated = true];
        Returns:
        Whether the deployment field is set.

      • getDeployment

        @Deprecated
Deployment getDeployment()
        Deprecated.
        temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.deployment is deprecated. See temporal/api/workflow/v1/message.proto;l=159
         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 `version`.
        .temporal.api.deployment.v1.Deployment deployment = 2 [deprecated = true];
        Returns:
        The deployment.

      • getDeploymentOrBuilder

        @Deprecated
DeploymentOrBuilder 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 `version`.
        .temporal.api.deployment.v1.Deployment deployment = 2 [deprecated = true];

      • getVersion

        java.lang.String getVersion()
         The Worker Deployment Version that completed the last workflow task of this workflow
 execution, in the form "<deployment_name>.<build_id>".
 Must be present if and only if `behavior` is set. An absent value means no workflow task is
 completed, or the workflow is unversioned.
 For child workflows of Pinned parents, this will be set to parent's Pinned Version when the
 the child starts so that child's first workflow task goes to the same Version as the parent.
 Note that if `versioning_override.behavior` is PINNED then `versioning_override.pinned_version`
 will override this value.
        string version = 5;
        Returns:
        The version.

      • getVersionBytes

        com.google.protobuf.ByteString getVersionBytes()
         The Worker Deployment Version that completed the last workflow task of this workflow
 execution, in the form "<deployment_name>.<build_id>".
 Must be present if and only if `behavior` is set. An absent value means no workflow task is
 completed, or the workflow is unversioned.
 For child workflows of Pinned parents, this will be set to parent's Pinned Version when the
 the child starts so that child's first workflow task goes to the same Version as the parent.
 Note that if `versioning_override.behavior` is PINNED then `versioning_override.pinned_version`
 will override this value.
        string version = 5;
        Returns:
        The bytes for version.

      • hasVersioningOverride

        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.
        .temporal.api.workflow.v1.VersioningOverride versioning_override = 3;
        Returns:
        Whether the versioningOverride field is set.

      • getVersioningOverride

        VersioningOverride 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.
        .temporal.api.workflow.v1.VersioningOverride versioning_override = 3;
        Returns:
        The versioningOverride.

      • getVersioningOverrideOrBuilder

        VersioningOverrideOrBuilder 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.
        .temporal.api.workflow.v1.VersioningOverride versioning_override = 3;

      • hasDeploymentTransition

        @Deprecated
boolean hasDeploymentTransition()
        Deprecated.
        temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.deployment_transition is deprecated. See temporal/api/workflow/v1/message.proto;l=193
         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];
        Returns:
        Whether the deploymentTransition field is set.

      • getDeploymentTransition

        @Deprecated
DeploymentTransition getDeploymentTransition()
        Deprecated.
        temporal.api.workflow.v1.WorkflowExecutionVersioningInfo.deployment_transition is deprecated. See temporal/api/workflow/v1/message.proto;l=193
         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];
        Returns:
        The deploymentTransition.

      • getDeploymentTransitionOrBuilder

        @Deprecated
DeploymentTransitionOrBuilder 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];

      • hasVersionTransition

        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 `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;
        Returns:
        Whether the versionTransition field is set.

      • getVersionTransition

        DeploymentVersionTransition 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 `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;
        Returns:
        The versionTransition.

      • getVersionTransitionOrBuilder

        DeploymentVersionTransitionOrBuilder 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 `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;