comments refined

Author: feiyang3cat

openapi/openapiv2.json

@@ -17964,7 +17964,7 @@
         },
         "timeSkippingConfig": {
           "$ref": "#/definitions/v1TimeSkippingConfig",
-          "description": "The propagated time-skipping config for the child workflow."
+          "description": "The propagated time-skipping configuration for the child workflow."
         }
       }
     },
@@ -18368,7 +18368,7 @@
           "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 accumulated skipped duration are inherited\n    from the current execution. The configured bound is shared across both the inherited skipped duration\n    and any additional duration skipped by the new run.\n(2) Retry and cron: both the configuration and accumulated skipped duration are inherited as recorded in the\n    StartWorkflowExecutionEvent of the current workflow and the accummulated skipped duration \n    of the current run won't be passed.\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."
+      "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."
     },
     "v1TimeoutFailureInfo": {
       "type": "object",
@@ -19652,7 +19652,7 @@
         },
         "timeSkippingConfig": {
           "$ref": "#/definitions/v1TimeSkippingConfig",
-          "description": "Time-skipping configuration for this workflow execution.\nIf not set, the time-skipping conf will not get updated upon request, \ni.e. the existing time-skipping conf will be preserved."
+          "description": "Time-skipping configuration for this workflow execution.\nIf not set, the time-skipping configuration is not updated by this request;\nthe existing configuration is preserved."
         }
       }
     },

openapi/openapiv3.yaml

@@ -15556,7 +15556,7 @@ components:
         timeSkippingConfig:
           allOf:
             - $ref: '#/components/schemas/TimeSkippingConfig'
-          description: The propagated time-skipping config for the child workflow.
+          description: The propagated time-skipping configuration for the child workflow.
     StartNexusOperationExecutionRequest:
       type: object
       properties:
@@ -16261,7 +16261,7 @@ components:
             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 accumulated skipped duration are inherited\n     from the current execution. The configured bound is shared across both the inherited skipped duration\n     and any additional duration skipped by the new run.\n (2) Retry and cron: both the configuration and accumulated skipped duration are inherited as recorded in the\n     StartWorkflowExecutionEvent of the current workflow and the accummulated skipped duration \n     of the current run won't be passed.\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."
+      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
       properties:
@@ -18211,7 +18211,10 @@ components:
         timeSkippingConfig:
           allOf:
             - $ref: '#/components/schemas/TimeSkippingConfig'
-          description: "Time-skipping configuration for this workflow execution.\n If not set, the time-skipping conf will not get updated upon request, \n i.e. the existing time-skipping conf will be preserved."
+          description: |-
+            Time-skipping configuration for this workflow execution.
+             If not set, the time-skipping configuration is not updated by this request;
+             the existing configuration is preserved.
     WorkflowExecutionOptionsUpdatedEventAttributes:
       type: object
       properties:

temporal/api/history/v1/message.proto

@@ -771,7 +771,7 @@ message StartChildWorkflowExecutionInitiatedEventAttributes {
     // Priority metadata
     temporal.api.common.v1.Priority priority = 20;
 
-    // The propagated time-skipping config for the child workflow.
+    // The propagated time-skipping configuration for the child workflow.
     temporal.api.workflow.v1.TimeSkippingConfig time_skipping_config = 21;
 }
 

temporal/api/workflow/v1/message.proto

@@ -580,8 +580,8 @@ message WorkflowExecutionOptions {
     temporal.api.common.v1.Priority priority = 2;
 
     // Time-skipping configuration for this workflow execution.
-    // If not set, the time-skipping conf will not get updated upon request, 
-    // i.e. the existing time-skipping conf will be preserved.
+    // If not set, the time-skipping configuration is not updated by this request;
+    // the existing configuration is preserved.
     TimeSkippingConfig time_skipping_config = 3;
 }
 
@@ -594,12 +594,11 @@ message WorkflowExecutionOptions {
 // 
 // Propagation behavior of time skipping:
 // The enabled flag, bound fields, and accumulated skipped duration are propagated to related executions as follows:
-// (1) Child workflows and continue-as-new: both the configuration and accumulated skipped duration are inherited
-//     from the current execution. The configured bound is shared across both the inherited skipped duration
-//     and any additional duration skipped by the new run.
-// (2) Retry and cron: both the configuration and accumulated skipped duration are inherited as recorded in the
-//     StartWorkflowExecutionEvent of the current workflow and the accummulated skipped duration 
-//     of the current run won't be passed.
+// (1) Child workflows and continue-as-new: both the configuration and the accumulated skipped duration are
+//     inherited from the current execution. The configured bound is shared between the inherited skipped
+//     duration and any additional duration skipped by the new run.
+// (2) Retry and cron: the configuration and accumulated skipped duration are inherited as recorded when the
+//     current workflow started; the accumulated skipped duration of the current run is not propagated.
 // (3) Reset: the new run retains the time-skipping configuration of the current execution. Because reset replays
 //     all events up to the reset point and re-applies any UpdateWorkflowExecutionOptions changes made after that
 //     point, the resulting run ends up with the same final time-skipping configuration as the previous run.
@@ -613,7 +612,7 @@ message TimeSkippingConfig {
     // Optional bound that limits the gap between the virtual time of this execution and wall-clock time.
     // Once the bound is reached, time skipping is automatically disabled,
     // but can be re-enabled by setting `enabled` to true via UpdateWorkflowExecutionOptions.
-    // This bound cannot be set to a value smaller than the current skipped duration of the current execution.
+    // This bound cannot be set to a value smaller than the execution's currently skipped duration.
     //
     // This is useful in testing scenarios where a workflow is expected to receive
     // signals, updates, or other external events while timers are in progress.