mv initial_skipped_time from config to start request, start attr, and start child attr

Author: feiyang3cat

openapi/openapiv2.json

@@ -11442,6 +11442,10 @@
         "timeSkippingConfig": {
           "$ref": "#/definitions/v1TimeSkippingConfig",
           "description": "Time-skipping configuration. If not set, time skipping is disabled."
+        },
+        "initialSkippedDuration": {
+          "type": "string",
+          "description": "If a workflow execution is started by a previous execution (parent-child workflow or continue-as-new) \nthat has already skipped some time, the accumulated skipped duration from that execution \ncan be passed to the new workflow execution through this field."
         }
       }
     },
@@ -17965,6 +17969,10 @@
         "timeSkippingConfig": {
           "$ref": "#/definitions/v1TimeSkippingConfig",
           "description": "The propagated time-skipping configuration for the child workflow."
+        },
+        "initialSkippedDuration": {
+          "type": "string",
+          "description": "Propagate the duration skipped to the child workflow."
         }
       }
     },
@@ -18362,10 +18370,6 @@
         "maxElapsedDuration": {
           "type": "string",
           "description": "Maximum elapsed time since time skipping was enabled.\nThis includes both skipped time and real time elapsing."
-        },
-        "initialSkippedDuration": {
-          "type": "string",
-          "description": "If this execution was started by a previous execution that had already skipped some time,\nit inherits the accumulated skipped duration from that execution through this field.\nThis field is set internally by the server and cannot be configured by the user."
         }
       },
       "description": "Configuration for time skipping during a workflow execution.\nWhen enabled, virtual time advances automatically whenever there is no in-flight work.\nIn-flight work includes activities, child workflows, Nexus operations, signal/cancel external workflow operations,\nand possibly other features added in the future.\nUser timers are not classified as in-flight work and will be skipped over.\nWhen time advances, it skips to the earlier of the next user timer or the configured bound, if either exists.\n\nPropagation behavior of time skipping:\nThe enabled flag, bound fields, and accumulated skipped duration are propagated to related executions as follows:\n(1) Child workflows and continue-as-new: both the configuration and the accumulated skipped duration are\n    inherited from the current execution. The configured bound is shared between the inherited skipped\n    duration and any additional duration skipped by the new run.\n(2) Retry and cron: the configuration and accumulated skipped duration are inherited as recorded when the\n    current workflow started; the accumulated skipped duration of the current run is not propagated.\n(3) Reset: the new run retains the time-skipping configuration of the current execution. Because reset replays\n    all events up to the reset point and re-applies any UpdateWorkflowExecutionOptions changes made after that\n    point, the resulting run ends up with the same final time-skipping configuration as the previous run."
@@ -19922,6 +19926,10 @@
         "timeSkippingConfig": {
           "$ref": "#/definitions/v1TimeSkippingConfig",
           "description": "Initial time-skipping configuration for this workflow execution, recorded at start time.\nThis may have been set explicitly via the start workflow request, or propagated from a\nparent/previous execution.\n\nThe configuration may be updated after start via UpdateWorkflowExecutionOptions, which\nwill be reflected in the WorkflowExecutionOptionsUpdatedEvent."
+        },
+        "initialSkippedDuration": {
+          "type": "string",
+          "description": "The time skipped by the previous execution that started this workflow.\nIt can happen in cases of child workflows and continue-as-new workflows."
         }
       },
       "title": "Always the first event in workflow history"

openapi/openapiv3.yaml

@@ -15557,6 +15557,10 @@ components:
           allOf:
             - $ref: '#/components/schemas/TimeSkippingConfig'
           description: The propagated time-skipping configuration for the child workflow.
+        initialSkippedDuration:
+          pattern: ^-?(?:0|[1-9][0-9]{0,11})(?:\.[0-9]{1,9})?s$
+          type: string
+          description: Propagate the duration skipped to the child workflow.
     StartNexusOperationExecutionRequest:
       type: object
       properties:
@@ -15810,6 +15814,10 @@ components:
           allOf:
             - $ref: '#/components/schemas/TimeSkippingConfig'
           description: Time-skipping configuration. If not set, time skipping is disabled.
+        initialSkippedDuration:
+          pattern: ^-?(?:0|[1-9][0-9]{0,11})(?:\.[0-9]{1,9})?s$
+          type: string
+          description: "If a workflow execution is started by a previous execution (parent-child workflow or continue-as-new) \n that has already skipped some time, the accumulated skipped duration from that execution \n can be passed to the new workflow execution through this field."
     StartWorkflowExecutionResponse:
       type: object
       properties:
@@ -16254,13 +16262,6 @@ components:
           description: |-
             Maximum elapsed time since time skipping was enabled.
              This includes both skipped time and real time elapsing.
-        initialSkippedDuration:
-          pattern: ^-?(?:0|[1-9][0-9]{0,11})(?:\.[0-9]{1,9})?s$
-          type: string
-          description: |-
-            If this execution was started by a previous execution that had already skipped some time,
-             it inherits the accumulated skipped duration from that execution through this field.
-             This field is set internally by the server and cannot be configured by the user.
       description: "Configuration for time skipping during a workflow execution.\n When enabled, virtual time advances automatically whenever there is no in-flight work.\n In-flight work includes activities, child workflows, Nexus operations, signal/cancel external workflow operations,\n and possibly other features added in the future.\n User timers are not classified as in-flight work and will be skipped over.\n When time advances, it skips to the earlier of the next user timer or the configured bound, if either exists.\n \n Propagation behavior of time skipping:\n The enabled flag, bound fields, and accumulated skipped duration are propagated to related executions as follows:\n (1) Child workflows and continue-as-new: both the configuration and the accumulated skipped duration are\n     inherited from the current execution. The configured bound is shared between the inherited skipped\n     duration and any additional duration skipped by the new run.\n (2) Retry and cron: the configuration and accumulated skipped duration are inherited as recorded when the\n     current workflow started; the accumulated skipped duration of the current run is not propagated.\n (3) Reset: the new run retains the time-skipping configuration of the current execution. Because reset replays\n     all events up to the reset point and re-applies any UpdateWorkflowExecutionOptions changes made after that\n     point, the resulting run ends up with the same final time-skipping configuration as the previous run."
     TimeoutFailureInfo:
       type: object
@@ -18558,6 +18559,12 @@ components:
 
              The configuration may be updated after start via UpdateWorkflowExecutionOptions, which
              will be reflected in the WorkflowExecutionOptionsUpdatedEvent.
+        initialSkippedDuration:
+          pattern: ^-?(?:0|[1-9][0-9]{0,11})(?:\.[0-9]{1,9})?s$
+          type: string
+          description: |-
+            The time skipped by the previous execution that started this workflow.
+             It can happen in cases of child workflows and continue-as-new workflows.
       description: Always the first event in workflow history
     WorkflowExecutionTerminatedEventAttributes:
       type: object

temporal/api/history/v1/message.proto

@@ -204,6 +204,10 @@ message WorkflowExecutionStartedEventAttributes {
     // The configuration may be updated after start via UpdateWorkflowExecutionOptions, which
     // will be reflected in the WorkflowExecutionOptionsUpdatedEvent.
     temporal.api.workflow.v1.TimeSkippingConfig time_skipping_config = 41;
+
+    // The time skipped by the previous execution that started this workflow.
+    // It can happen in cases of child workflows and continue-as-new workflows.
+    google.protobuf.Duration initial_skipped_duration = 42;
 }
 
 // Wrapper for a target deployment version that the SDK declined to upgrade to.
@@ -773,6 +777,9 @@ message StartChildWorkflowExecutionInitiatedEventAttributes {
 
     // The propagated time-skipping configuration for the child workflow.
     temporal.api.workflow.v1.TimeSkippingConfig time_skipping_config = 21;
+
+    // Propagate the duration skipped to the child workflow.
+    google.protobuf.Duration initial_skipped_duration = 30;
 }
 
 message StartChildWorkflowExecutionFailedEventAttributes {

temporal/api/workflow/v1/message.proto

@@ -625,11 +625,6 @@ message TimeSkippingConfig {
         // (-- api-linter: core::0142::time-field-names=disabled --)
         google.protobuf.Duration max_elapsed_duration = 5;
     }
-
-    // If this execution was started by a previous execution that had already skipped some time,
-    // it inherits the accumulated skipped duration from that execution through this field.
-    // This field is set internally by the server and cannot be configured by the user.
-    google.protobuf.Duration initial_skipped_duration = 3;
 }
 
 // Used to override the versioning behavior (and pinned deployment version, if applicable) of a

temporal/api/workflowservice/v1/request_response.proto

@@ -199,8 +199,15 @@ message StartWorkflowExecutionRequest {
     temporal.api.common.v1.Priority priority = 27;
     // Deployment Options of the worker who will process the eager task. Passed when `request_eager_execution=true`.
     temporal.api.deployment.v1.WorkerDeploymentOptions eager_worker_deployment_options = 28;
+
     // Time-skipping configuration. If not set, time skipping is disabled.
     temporal.api.workflow.v1.TimeSkippingConfig time_skipping_config = 29;
+
+    // If a workflow execution is started by a previous execution (parent-child workflow or continue-as-new) 
+    // that has already skipped some time, the accumulated skipped duration from that execution 
+    // can be passed to the new workflow execution through this field.
+    google.protobuf.Duration initial_skipped_duration = 30;
+
 }
 
 message StartWorkflowExecutionResponse {