[Worker Versioning GA]: Add autoUpgrade information inside of events

openapi/openapiv2.json

@@ -12065,6 +12065,21 @@
       ],
       "default": "INDEXED_VALUE_TYPE_UNSPECIFIED"
     },
+    "v1InheritedAutoUpgradeInfo": {
+      "type": "object",
+      "properties": {
+        "sourceDeploymentVersion": {
+          "$ref": "#/definitions/v1WorkerDeploymentVersion",
+          "description": "The source deployment version of the parent/previous workflow."
+        },
+        "sourceDeploymentRevisionNumber": {
+          "type": "string",
+          "format": "int64",
+          "description": "The revision number of the source deployment version of the parent/previous workflow."
+        }
+      },
+      "description": "Used as part of WorkflowExecutionStartedEventAttributes to pass down the AutoUpgrade behavior and source deployment version \nto a workflow execution whose parent/previous workflow has an AutoUpgrade behavior."
+    },
     "v1Input": {
       "type": "object",
       "properties": {
@@ -17194,7 +17209,11 @@
         },
         "inheritedPinnedVersion": {
           "$ref": "#/definitions/v1WorkerDeploymentVersion",
-          "description": "If present, the new workflow should start on this version with pinned base behavior.\nChild of pinned parent will inherit the parent's version if the Child's Task Queue belongs to that version.\n\nNew run initiated by workflow ContinueAsNew of pinned run, will inherit the previous run's version if the\nnew run's Task Queue belongs to that version.\n\nNew run initiated by workflow Cron will never inherit.\n\nNew run initiated by workflow Retry will only inherit if the retried run is effectively pinned at the time\nof retry, and the retried run inherited a pinned version when it started (ie. it is a child of a pinned\nparent, or a CaN of a pinned run, and is running on a Task Queue in the inherited version).\n\nPinned override is inherited if Task Queue of new run is compatible with the override version.\nOverride is inherited separately and takes precedence over inherited base version."
+          "description": "If present, the new workflow should start on this version with pinned base behavior.\nChild of pinned parent will inherit the parent's version if the Child's Task Queue belongs to that version.\n\nNew run initiated by workflow ContinueAsNew of pinned run, will inherit the previous run's version if the\nnew run's Task Queue belongs to that version.\n\nNew run initiated by workflow Cron will never inherit.\n\nNew run initiated by workflow Retry will only inherit if the retried run is effectively pinned at the time\nof retry, and the retried run inherited a pinned version when it started (ie. it is a child of a pinned\nparent, or a CaN of a pinned run, and is running on a Task Queue in the inherited version).\n\nPinned override is inherited if Task Queue of new run is compatible with the override version.\nOverride is inherited separately and takes precedence over inherited base version.\n\nNote: This field is mutually exclusive with inherited_auto_upgrade_info."
+        },
+        "inheritedAutoUpgradeInfo": {
+          "$ref": "#/definitions/v1InheritedAutoUpgradeInfo",
+          "description": "If present, the new workflow will commence with AutoUpgrade behavior on the current version of it's Task Queue's Deployment. \nUserData inconsistencies put forward by the eventual consistencies of the matching partitions shall be resolved with the help\nof the revision number and source deployment version passed in this field. This shall schedule the first workflow task of the new run\non the source deployment version or the current deployment version of the Task Queue's Deployment.\nAfter the first workflow task, the effective behavior of the workflow depends on worker sent values in subsequent workflow tasks.\nNote: This field is only populated if the Task Queue on which the new run is scheduled belongs to a deployment on which the parent run is running.\n\nNew run initiated by workflow ContinueAsNew of an AutoUpgrade run, or a child workflow of an AutoUpgrade parent, will inherit the \nprevious run's AutoUpgrade behavior and the source deployment version passed in this field.\nBoth Matching and History service shall then use the revision number to determine the deployment version on which the new run will \ndispatch its first workflow task. This deployment version shall either be the source deployment version, passed down from the parent run,\nor the current deployment version of the Task Queue's Deployment.\n\nNew run initiated by workflow Cron will never inherit the AutoUpgrade behavior.\n\nNew run initiated by workflow Retry will only inherit this field if the retried run is effectively AutoUpgrade at the time\nof retry, and the retried run inherited AutoUpgrade behavior when it started (ie. it is a child of a AutoUpgrade\nparent, or a CaN of a AutoUpgrade run, and is running on the same deployment as that of the parent). \n\nNote: This field is mutually exclusive with `inherited_pinned_version."
         },
         "eagerExecutionAccepted": {
           "type": "boolean",
@@ -17349,7 +17368,7 @@
       "properties": {
         "behavior": {
           "$ref": "#/definitions/v1VersioningBehavior",
-          "description": "Versioning behavior determines how the server should treat this execution when workers are\nupgraded. When present it means this workflow execution is versioned; UNSPECIFIED means\nunversioned. See the comments in `VersioningBehavior` enum for more info about different\nbehaviors.\nThis field is first set after an execution completes its first workflow task on a versioned\nworker, and set again on completion of every subsequent workflow task.\nFor child workflows of Pinned parents, this will be set to Pinned (along with `deployment_version`) when\nthe the child starts so that child's first workflow task goes to the same Version as the\nparent. After the first workflow task, it depends on the child workflow itself if it wants\nto stay pinned or become unpinned (according to Versioning Behavior set in the worker).\nNote that `behavior` is overridden by `versioning_override` if the latter is present."
+          "description": "Versioning behavior determines how the server should treat this execution when workers are\nupgraded. When present it means this workflow execution is versioned; UNSPECIFIED means\nunversioned. See the comments in `VersioningBehavior` enum for more info about different\nbehaviors.\nThis field is first set after an execution completes its first workflow task on a versioned\nworker, and set again on completion of every subsequent workflow task.\nFor child workflows of Pinned parents, this will be set to Pinned (along with `deployment_version`) when\nthe the child starts so that child's first workflow task goes to the same Version as the\nparent. After the first workflow task, it depends on the child workflow itself if it wants\nto stay pinned or become unpinned (according to Versioning Behavior set in the worker).\n\nFor child workflows of AutoUpgrade parents: before dispatching the child's first workflow\ntask, this field is set to AutoUpgrade behavior. This occurs only if the child\nworkflow’s task queue belongs to the same deployment version as the parent workflow’s\ntask queue.\n\nFor continue-as-new runs of AutoUpgrade executions: before dispatching the first workflow\ntask of the next run, this field is set to AutoUpgrade behavior. This occurs only\nif the next run’s workflow task queue belongs to the same deployment version as the\nprevious run’s workflow task queue.\nNote that `behavior` is overridden by `versioning_override` if the latter is present."
         },
         "deployment": {
           "$ref": "#/definitions/v1Deployment",
@@ -17361,7 +17380,7 @@
         },
         "deploymentVersion": {
           "$ref": "#/definitions/v1WorkerDeploymentVersion",
-          "description": "The Worker Deployment Version that completed the last workflow task of this workflow execution.\nAn absent value means no workflow task is completed, or the workflow is unversioned.\nIf present, and `behavior` is UNSPECIFIED, the last task of this workflow execution was completed\nby a worker that is not using versioning but _is_ passing Deployment Name and Build ID.\n\nFor child workflows of Pinned parents, this will be set to the parent's Pinned Version when\nthe child starts, so that the child's first workflow task goes to the same Version as the parent.\nNote that if `versioning_override.behavior` is PINNED then `versioning_override.pinned_version`\nwill override this value."
+          "description": "The Worker Deployment Version that completed the last workflow task of this workflow execution.\nAn absent value means no workflow task is completed, or the workflow is unversioned.\nIf present, and `behavior` is UNSPECIFIED, the last task of this workflow execution was completed\nby a worker that is not using versioning but _is_ passing Deployment Name and Build ID.\n\nFor child workflows of Pinned parents, this will be set to the parent's Pinned Version when\nthe child starts, so that the child's first workflow task goes to the same Version as the parent.\n\nFor child workflows of AutoUpgrade parent workflows:\nBefore dispatching the child's first workflow task, this field is set to the deployment\nversion on which the parent is running. This happens only when the child workflow's task\nqueue belongs to the same deployment version as the parent workflow's task queue. The\nfirst workflow task of the child workflow will then be dispatched to either:\n  - this deployment version that is passed down from the parent, or\n  - the current deployment version of the task queue's Deployment.\n\nFor continue-as-new workflow runs of an AutoUpgrade execution:\nBefore dispatching the new run's first workflow task, this field is set to the deployment\nversion on which the previous run was operating. This happens only when the task queue for\nthe next run belongs to the same deployment version as the previous run's task queue. The\nfirst workflow task of the next run will then be dispatched to either:\n  - this deployment version that is passed down from the previous execution, or\n  - the current deployment version of the task queue's Deployment.\n\nNote that if `versioning_override.behavior` is PINNED then `versioning_override.pinned_version`\nwill override this value."
         },
         "versioningOverride": {
           "$ref": "#/definitions/v1VersioningOverride",

openapi/openapiv3.yaml

@@ -8918,6 +8918,17 @@ components:
       description: |-
         History events are the method by which Temporal SDKs advance (or recreate) workflow state.
          See the `EventType` enum for more info about what each event is for.
+    InheritedAutoUpgradeInfo:
+      type: object
+      properties:
+        sourceDeploymentVersion:
+          allOf:
+            - $ref: '#/components/schemas/WorkerDeploymentVersion'
+          description: The source deployment version of the parent/previous workflow.
+        sourceDeploymentRevisionNumber:
+          type: string
+          description: The revision number of the source deployment version of the parent/previous workflow.
+      description: "Used as part of WorkflowExecutionStartedEventAttributes to pass down the AutoUpgrade behavior and source deployment version \n to a workflow execution whose parent/previous workflow has an AutoUpgrade behavior."
     Input:
       type: object
       properties:
@@ -14689,6 +14700,12 @@ components:
 
              Pinned override is inherited if Task Queue of new run is compatible with the override version.
              Override is inherited separately and takes precedence over inherited base version.
+
+             Note: This field is mutually exclusive with inherited_auto_upgrade_info.
+        inheritedAutoUpgradeInfo:
+          allOf:
+            - $ref: '#/components/schemas/InheritedAutoUpgradeInfo'
+          description: "If present, the new workflow will commence with AutoUpgrade behavior on the current version of it's Task Queue's Deployment. \n UserData inconsistencies put forward by the eventual consistencies of the matching partitions shall be resolved with the help\n of the revision number and source deployment version passed in this field. This shall schedule the first workflow task of the new run\n on the source deployment version or the current deployment version of the Task Queue's Deployment.\n After the first workflow task, the effective behavior of the workflow depends on worker sent values in subsequent workflow tasks.\n Note: This field is only populated if the Task Queue on which the new run is scheduled belongs to a deployment on which the parent run is running.\n\n New run initiated by workflow ContinueAsNew of an AutoUpgrade run, or a child workflow of an AutoUpgrade parent, will inherit the \n previous run's AutoUpgrade behavior and the source deployment version passed in this field.\n Both Matching and History service shall then use the revision number to determine the deployment version on which the new run will \n dispatch its first workflow task. This deployment version shall either be the source deployment version, passed down from the parent run,\n or the current deployment version of the Task Queue's Deployment.\n\n New run initiated by workflow Cron will never inherit the AutoUpgrade behavior.\n\n New run initiated by workflow Retry will only inherit this field if the retried run is effectively AutoUpgrade at the time\n of retry, and the retried run inherited AutoUpgrade behavior when it started (ie. it is a child of a AutoUpgrade\n parent, or a CaN of a AutoUpgrade run, and is running on the same deployment as that of the parent). \n \n Note: This field is mutually exclusive with `inherited_pinned_version."
         eagerExecutionAccepted:
           type: boolean
           description: |-
@@ -14832,6 +14849,16 @@ components:
              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).
+
+             For child workflows of AutoUpgrade parents: before dispatching the child's first workflow
+             task, this field is set to AutoUpgrade behavior. This occurs only if the child
+             workflow’s task queue belongs to the same deployment version as the parent workflow’s
+             task queue.
+
+             For continue-as-new runs of AutoUpgrade executions: before dispatching the first workflow
+             task of the next run, this field is set to AutoUpgrade behavior. This occurs only
+             if the next run’s workflow task queue belongs to the same deployment version as the
+             previous run’s workflow task queue.
              Note that `behavior` is overridden by `versioning_override` if the latter is present.
           format: enum
         deployment:
@@ -14859,6 +14886,23 @@ components:
 
              For child workflows of Pinned parents, this will be set to the parent's Pinned Version when
              the child starts, so that the child's first workflow task goes to the same Version as the parent.
+
+             For child workflows of AutoUpgrade parent workflows:
+             Before dispatching the child's first workflow task, this field is set to the deployment
+             version on which the parent is running. This happens only when the child workflow's task
+             queue belongs to the same deployment version as the parent workflow's task queue. The
+             first workflow task of the child workflow will then be dispatched to either:
+               - this deployment version that is passed down from the parent, or
+               - the current deployment version of the task queue's Deployment.
+
+             For continue-as-new workflow runs of an AutoUpgrade execution:
+             Before dispatching the new run's first workflow task, this field is set to the deployment
+             version on which the previous run was operating. This happens only when the task queue for
+             the next run belongs to the same deployment version as the previous run's task queue. The
+             first workflow task of the next run will then be dispatched to either:
+               - this deployment version that is passed down from the previous execution, or
+               - the current deployment version of the task queue's Deployment.
+
              Note that if `versioning_override.behavior` is PINNED then `versioning_override.pinned_version`
              will override this value.
         versioningOverride:

temporal/api/deployment/v1/message.proto

@@ -293,3 +293,12 @@ message RoutingConfig {
     // to any field of this message to achieve eventual consistency between task queues and their partitions.
     int64 revision_number = 10;
 }
+
+// Used as part of WorkflowExecutionStartedEventAttributes to pass down the AutoUpgrade behavior and source deployment version 
+// to a workflow execution whose parent/previous workflow has an AutoUpgrade behavior.
+message InheritedAutoUpgradeInfo {
+    // The source deployment version of the parent/previous workflow.
+    temporal.api.deployment.v1.WorkerDeploymentVersion source_deployment_version = 1;
+    // The revision number of the source deployment version of the parent/previous workflow.
+    int64 source_deployment_revision_number = 2;
+}