Skip to content

delete max elasped duration #787

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
feiyang3cat wants to merge 1 commit into
base: master
Choose a base branch
from
+2 −17
Open

delete max elasped duration #787

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 0 additions & 4 deletions openapi/openapiv2.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19472,10 +19472,6 @@
"maxSkippedDuration": {
"type": "string",
"description": "Maximum total virtual time that can be skipped."
},
"maxElapsedDuration": {
"type": "string",
"description": "Maximum elapsed time since time skipping was enabled.\nThis includes both skipped time and real time elapsing."
}
},
"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."
Expand Down
6 changes: 0 additions & 6 deletions openapi/openapiv3.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17238,12 +17238,6 @@ components:
pattern: ^-?(?:0|[1-9][0-9]{0,11})(?:\.[0-9]{1,9})?s$
type: string
description: Maximum total virtual time that can be skipped.
maxElapsedDuration:
pattern: ^-?(?:0|[1-9][0-9]{0,11})(?:\.[0-9]{1,9})?s$
type: string
description: |-
Maximum elapsed time since time skipping was enabled.
This includes both skipped time and real time elapsing.
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
Expand Down
9 changes: 2 additions & 7 deletions temporal/api/workflow/v1/message.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -609,8 +609,8 @@ message WorkflowExecutionOptions {
// 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.
message TimeSkippingConfig {
reserved 2, 6;
reserved "disable_propagation", "max_target_time";
reserved 2, 5, 6;
Copy link
Copy Markdown
Contributor

@prathyushpv prathyushpv May 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nobody uses this feature so far. So I wonder do we need to reserve these fields, and just reuse these numbers?

reserved "disable_propagation", "max_elapsed_duration", "max_target_time";

// Enables or disables time skipping for this workflow execution.
bool enabled = 1;
Expand All @@ -625,11 +625,6 @@ message TimeSkippingConfig {
oneof bound {
Copy link
Copy Markdown
Contributor

@prathyushpv prathyushpv May 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this oneof field if we only have max_skipped_duration? Are we planning to keep add more option in the future?

// Maximum total virtual time that can be skipped.
google.protobuf.Duration max_skipped_duration = 4;

// Maximum elapsed time since time skipping was enabled.
// This includes both skipped time and real time elapsing.
// (-- api-linter: core::0142::time-field-names=disabled --)
google.protobuf.Duration max_elapsed_duration = 5;
}
}

Expand Down
Loading