refine propagation design of TimeSkippingConfig

Author: feiyang3cat

openapi/openapiv2.json

@@ -17134,9 +17134,9 @@
           "type": "boolean",
           "description": "Enables or disables time skipping for this workflow execution."
         },
-        "disablePropagation": {
+        "disableChildWorkflowPropagation": {
           "type": "boolean",
-          "description": "By default, the time skipping configuration is propagated to transitively related workflows.\nIf set, transitively related workflows will be started with time skipping disabled."
+          "description": "By default, the time skipping configuration (enabled and bound) is propagated to child workflows,\nusing the same values as the parent workflow.\nIf set, child workflows will be started with time skipping disabled.\nRegardless of this field, the start time of the child workflow uses the parent's virtual time."
         },
         "maxSkippedDuration": {
           "type": "string",
@@ -17150,6 +17150,10 @@
           "type": "string",
           "format": "date-time",
           "description": "Absolute virtual timestamp at which time skipping is disabled.\nTime skipping will not advance beyond this point."
+        },
+        "propagatedSkippedDuration": {
+          "type": "string",
+          "description": "If this execution was started by a previous execution that already skipped some time,\nit inherits the virtual time through the propagated skipped duration."
         }
       },
       "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."

openapi/openapiv3.yaml

@@ -15110,11 +15110,13 @@ components:
         enabled:
           type: boolean
           description: Enables or disables time skipping for this workflow execution.
-        disablePropagation:
+        disableChildWorkflowPropagation:
           type: boolean
           description: |-
-            By default, the time skipping configuration is propagated to transitively related workflows.
-             If set, transitively related workflows will be started with time skipping disabled.
+            By default, the time skipping configuration (enabled and bound) is propagated to child workflows,
+             using the same values as the parent workflow.
+             If set, child workflows will be started with time skipping disabled.
+             Regardless of this field, the start time of the child workflow uses the parent's virtual time.
         maxSkippedDuration:
           pattern: ^-?(?:0|[1-9][0-9]{0,11})(?:\.[0-9]{1,9})?s$
           type: string
@@ -15131,6 +15133,12 @@ components:
             Absolute virtual timestamp at which time skipping is disabled.
              Time skipping will not advance beyond this point.
           format: date-time
+        propagatedSkippedDuration:
+          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 already skipped some time,
+             it inherits the virtual time through the propagated skipped duration.
       description: |-
         Configuration for time skipping during a workflow execution.
          When enabled, virtual time advances automatically whenever there is no in-flight work.

temporal/api/workflow/v1/message.proto

@@ -590,36 +590,30 @@ message WorkflowExecutionOptions {
 // User timers are not classified as in-flight work and will be skipped over.
 // When time advances, it skips to the earlier of the next user timer or the configured bound, if either exists.
 message TimeSkippingConfig {
+    reserved 2;
+    reserved "disable_propagation";
 
     // Enables or disables time skipping for this workflow execution.
     bool enabled = 1;
 
-    // By default, the time skipping configuration is propagated to transitively related workflows.
-    // If set, transitively related workflows will be started with time skipping disabled.
-    bool disable_propagation = 2;
+    // By default, the time skipping configuration (enabled and bound) is propagated to child workflows,
+    // using the same values as the parent workflow.
+    // If set, child workflows will be started with time skipping disabled.
+    // Regardless of this field, the start time of the child workflow uses the parent's virtual time.
+    bool disable_child_workflow_propagation = 3;
 
-    // Optional bound that limits how long time skipping remains active.
-    // Once the bound is reached, time skipping is automatically disabled.
-    // It can later be re-enabled via UpdateWorkflowExecutionOptions.
+    // Optional bound that limits how far virtual time can advance while time skipping is active.
+    // Once the bound is reached, time skipping is automatically disabled,
+    // but can be re-enabled via UpdateWorkflowExecutionOptions.
     //
-    // This is particularly useful in testing scenarios where workflows
-    // are expected to receive signals, updates, or other events while
-    // timers are in progress.
+    // This is useful in testing scenarios where a workflow is expected to receive
+    // signals, updates, or other external events while timers are in progress.
     //
-    // The bound is propagated to transitively related workflows differently
-    // depending on the type and semantics of the related workflow:
-    // - Child workflows: the bound is propagated with the same value as the
-    //   parent workflow, and the child begins execution at the parent's virtual
-    //   time. If the bound is duration-based, each child calculates its skipped
-    //   duration independently from its own start.
-    //
-    // - Continue-as-new workflows: the bound is propagated with the same value
-    //   as the previous workflow. If the bound is duration-based, the
-    //   continue-as-new workflow shares the accumulated duration with the
-    //   previous workflow.
-    //
-    // - Reset workflows: the entire TimeSkippingConfig is restored to the value
-    //   it had at the event this workflow was reset to.
+    // Bound scope:
+    // - Each bound is independent for each workflow execution.
+    //   When a bound is propagated to a child workflow, the child's bound is only applied to that child execution.
+    // - Continue-as-new is an exception: continued workflow executions are treated as extensions of the
+    //   original execution, so the bound is shared across all executions in the chain.
     oneof bound {
 
         // Maximum total virtual time that can be skipped.
@@ -634,6 +628,11 @@ message TimeSkippingConfig {
         // Time skipping will not advance beyond this point.
         google.protobuf.Timestamp max_target_time = 6;
     }
+
+    // If this execution was started by a previous execution that already skipped some time,
+    // it inherits the virtual time through the propagated skipped duration.
+    google.protobuf.Duration propagated_skipped_duration = 7;
+
 }
 
 // Used to override the versioning behavior (and pinned deployment version, if applicable) of a