refine design of TimeSkippingConfig

Author: feiyang3cat

openapi/openapiv2.json

@@ -17100,9 +17100,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",

openapi/openapiv3.yaml

@@ -15076,11 +15076,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

temporal/api/workflow/v1/message.proto

@@ -594,32 +594,27 @@ message TimeSkippingConfig {
     // 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;
-
-    // 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.
-    //
-    // This is particularly useful in testing scenarios where workflows
-    // are expected to receive signals, updates, or other 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.
+    reserved 2;
+    reserved "disable_propagation";
+
+    // 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 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.
     //
-    // - 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.
+    // This is useful in testing scenarios where a workflow is expected to receive
+    // signals, updates, or other external events while timers are in progress.
     //
-    // - Reset workflows: the entire TimeSkippingConfig is restored to the value
-    //   it had at the event this workflow was reset to.
+    // Bound scope:
+    // - Each workflow execution manages its own bound independently.
+    //   When propagated to a child workflow, the child's bound applies only 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.