-
Notifications
You must be signed in to change notification settings - Fork 90
automatic time-skipping #740
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.
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
Changes from all commits
e992c90
63ff7b3
7e634d9
d57db93
bbdabef
14eb5f9
1fca0f0
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -566,6 +566,56 @@ message WorkflowExecutionOptions { | |||||
|
|
||||||
| // If set, overrides the workflow's priority sent by the SDK. | ||||||
| temporal.api.common.v1.Priority priority = 2; | ||||||
|
|
||||||
| // Time-skipping configuration for this workflow execution. | ||||||
feiyang3cat marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
| // If not set, the time-skipping conf will not get updated upon request, | ||||||
| // i.e. the existing time-skipping conf will be preserved. | ||||||
| TimeSkippingConfig time_skipping_config = 3; | ||||||
| } | ||||||
|
|
||||||
feiyang3cat marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
| // Configuration for time skipping during a workflow execution. | ||||||
| // When enabled, virtual time advances automatically whenever there is no in-flight work. | ||||||
| // In-flight work includes activities, child workflows, Nexus operations, signal/cancel external workflow operations, | ||||||
| // and possibly other features added in the future. | ||||||
| // 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 { | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. do we need to add this in to child workflow command?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Specifically, I don't imagine we will need to set childWorkflow time-skipping config thru command when users use SDK testing env. And in general, I think we may keep this as complex as the current version and only consider adding more when SDK really needs it.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. no strong opinion either way given we support time skipping config propagation. Please track the potential work item somewhere though.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. oh yes, I will follow up on this, but I want to change the topic a bit. here what I think we should follow up is on how to provide more user-friendly configurations for complex testing scenarios with child wfs/start-as-new/etc, than a specific tech solution to add config in commands. And that will be an later phase working with SDK integrations.
yycptt marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
|
||||||
| // Enables or disables time skipping for this workflow execution. | ||||||
| // By default, this field is propagated to transitively related workflows (child workflows/start-as-new/reset) | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
| // at the time they are started. | ||||||
| // Changes made after a transitively related workflow has started are not propagated. | ||||||
| bool enabled = 1; | ||||||
|
|
||||||
| // If set, the enabled field is not propagated to transitively related workflows. | ||||||
| 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. | ||||||
| // | ||||||
| // This bound is not propagated to transitively related workflows. | ||||||
| // When bound is also needed for transitively related workflows, | ||||||
| // it is recommended to set disable_propagation to true | ||||||
| // and configure TimeSkippingConfig explicitly for transitively related workflows. | ||||||
| oneof bound { | ||||||
feiyang3cat marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
|
||||||
| // 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; | ||||||
|
|
||||||
| // Absolute virtual timestamp at which time skipping is disabled. | ||||||
| // Time skipping will not advance beyond this point. | ||||||
| google.protobuf.Timestamp max_target_time = 6; | ||||||
| } | ||||||
| } | ||||||
|
|
||||||
| // Used to override the versioning behavior (and pinned deployment version, if applicable) of a | ||||||
|
|
||||||
Uh oh!
There was an error while loading. Please reload this page.