[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\nA new 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\nA new run initiated by workflow Cron will never inherit.\n\nA new 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 commences with AutoUpgrade behavior. Before dispatching the\nfirst workflow task, this field is set to the deployment version on which the parent/\nprevious run was operating. This inheritance only happens when the task queues belong to\nthe same deployment version. The first workflow task will then be dispatched to either\nthis inherited deployment version, or the current deployment version of the task queue's\nDeployment. After the first workflow task, the effective behavior depends on worker-sent\nvalues in subsequent workflow tasks.\n\nInheritance rules:\n  - ContinueAsNew and child workflows: inherit AutoUpgrade behavior and deployment version\n  - Cron: never inherits\n  - Retry: inherits only if the retried run is effectively AutoUpgrade at the time of\n    retry, and inherited AutoUpgrade behavior when it started (i.e. it is a child of an\n    AutoUpgrade parent or ContinueAsNew of an AutoUpgrade run, running on the same\n    deployment as the parent/previous run)\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 and continue-as-new runs of AutoUpgrade parents/executions: before\ndispatching the first workflow task, this field is set to AutoUpgrade behavior. This\noccurs only if the child's/next run's task queue belongs to the same deployment version \nas the parent's/previous run's task queue.\n\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 and continue-as-new runs of AutoUpgrade parents, before dispatching\nthe first workflow task, this field is set to the deployment version on which the\nparent/previous run was operating. This inheritance only happens when the task queues\nbelong to the same deployment version. The first workflow task will then be dispatched\nto either this inherited deployment version, or the current deployment version of the\ntask 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:
@@ -14678,17 +14689,23 @@ components:
             If present, the new workflow should start on this version with pinned base behavior.
              Child of pinned parent will inherit the parent's version if the Child's Task Queue belongs to that version.
 
-             New run initiated by workflow ContinueAsNew of pinned run, will inherit the previous run's version if the
+             A new run initiated by workflow ContinueAsNew of pinned run, will inherit the previous run's version if the
              new run's Task Queue belongs to that version.
 
-             New run initiated by workflow Cron will never inherit.
+             A new run initiated by workflow Cron will never inherit.
 
-             New run initiated by workflow Retry will only inherit if the retried run is effectively pinned at the time
+             A new run initiated by workflow Retry will only inherit if the retried run is effectively pinned at the time
              of retry, and the retried run inherited a pinned version when it started (ie. it is a child of a pinned
              parent, or a CaN of a pinned run, and is running on a Task Queue in the inherited version).
 
              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 commences with AutoUpgrade behavior. Before dispatching the\n first workflow task, this field is set to the deployment version on which the parent/\n previous run was operating. This inheritance only happens when the task queues belong to\n the same deployment version. The first workflow task will then be dispatched to either\n this inherited deployment version, or the current deployment version of the task queue's\n Deployment. After the first workflow task, the effective behavior depends on worker-sent\n values in subsequent workflow tasks.\n\n Inheritance rules:\n   - ContinueAsNew and child workflows: inherit AutoUpgrade behavior and deployment version\n   - Cron: never inherits\n   - Retry: inherits only if the retried run is effectively AutoUpgrade at the time of\n     retry, and inherited AutoUpgrade behavior when it started (i.e. it is a child of an\n     AutoUpgrade parent or ContinueAsNew of an AutoUpgrade run, running on the same\n     deployment as the parent/previous run)\n \n Note: This field is mutually exclusive with `inherited_pinned_version."
         eagerExecutionAccepted:
           type: boolean
           description: |-
@@ -14821,18 +14838,7 @@ components:
             - VERSIONING_BEHAVIOR_PINNED
             - VERSIONING_BEHAVIOR_AUTO_UPGRADE
           type: string
-          description: |-
-            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 `deployment_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.
+          description: "Versioning behavior determines how the server should treat this execution when workers are\n upgraded. When present it means this workflow execution is versioned; UNSPECIFIED means\n unversioned. See the comments in `VersioningBehavior` enum for more info about different\n behaviors.\n This field is first set after an execution completes its first workflow task on a versioned\n worker, and set again on completion of every subsequent workflow task.\n For child workflows of Pinned parents, this will be set to Pinned (along with `deployment_version`) when\n the the child starts so that child's first workflow task goes to the same Version as the\n parent. After the first workflow task, it depends on the child workflow itself if it wants\n to stay pinned or become unpinned (according to Versioning Behavior set in the worker).\n\n For child workflows and continue-as-new runs of AutoUpgrade parents/executions: before\n dispatching the first workflow task, this field is set to AutoUpgrade behavior. This\n occurs only if the child's/next run's task queue belongs to the same deployment version \n as the parent's/previous run's task queue.\n \n Note that `behavior` is overridden by `versioning_override` if the latter is present."
           format: enum
         deployment:
           allOf:
@@ -14859,6 +14865,14 @@ 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 and continue-as-new runs of AutoUpgrade parents, before dispatching
+             the first workflow task, this field is set to the deployment version on which the
+             parent/previous run was operating. This inheritance only happens when the task queues
+             belong to the same deployment version. The first workflow task will then be dispatched
+             to either this inherited deployment version, 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;
+}

temporal/api/history/v1/message.proto

@@ -136,22 +136,45 @@ message WorkflowExecutionStartedEventAttributes {
     reserved 36;
     reserved "parent_pinned_deployment_version";
 
+
     // If present, the new workflow should start on this version with pinned base behavior.
     // Child of pinned parent will inherit the parent's version if the Child's Task Queue belongs to that version.
     //
-    // New run initiated by workflow ContinueAsNew of pinned run, will inherit the previous run's version if the
+    // A new run initiated by workflow ContinueAsNew of pinned run, will inherit the previous run's version if the
     // new run's Task Queue belongs to that version.
     //
-    // New run initiated by workflow Cron will never inherit.
+    // A new run initiated by workflow Cron will never inherit.
     //
-    // New run initiated by workflow Retry will only inherit if the retried run is effectively pinned at the time
+    // A new run initiated by workflow Retry will only inherit if the retried run is effectively pinned at the time
     // of retry, and the retried run inherited a pinned version when it started (ie. it is a child of a pinned
     // parent, or a CaN of a pinned run, and is running on a Task Queue in the inherited version).
     //
     // 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. 
     temporal.api.deployment.v1.WorkerDeploymentVersion inherited_pinned_version = 37;
 
+    // If present, the new workflow commences with AutoUpgrade behavior. Before dispatching the
+    // first workflow task, this field is set to the deployment version on which the parent/
+    // previous run was operating. This inheritance only happens when the task queues belong to
+    // the same deployment version. The first workflow task will then be dispatched to either
+    // this inherited deployment version, or the current deployment version of the task queue's
+    // Deployment. After the first workflow task, the effective behavior depends on worker-sent
+    // values in subsequent workflow tasks.
+    //
+    // Inheritance rules:
+    //   - ContinueAsNew and child workflows: inherit AutoUpgrade behavior and deployment version
+    //   - Cron: never inherits
+    //   - Retry: inherits only if the retried run is effectively AutoUpgrade at the time of
+    //     retry, and inherited AutoUpgrade behavior when it started (i.e. it is a child of an
+    //     AutoUpgrade parent or ContinueAsNew of an AutoUpgrade run, running on the same
+    //     deployment as the parent/previous run)
+    // 
+    // Note: This field is mutually exclusive with `inherited_pinned_version. 
+    temporal.api.deployment.v1.InheritedAutoUpgradeInfo inherited_auto_upgrade_info = 39;
+
+
     // A boolean indicating whether the SDK has asked to eagerly execute the first workflow task for this workflow and
     // eager execution was accepted by the server.
     // Only populated by server with version >= 1.29.0.