Skip to content

[don't merge] time skipping sleep: need review and server PR#786

Open
feiyang3cat wants to merge 1 commit into
mainfrom
patch/ts
Open

[don't merge] time skipping sleep: need review and server PR#786
feiyang3cat wants to merge 1 commit into
mainfrom
patch/ts

Conversation

@feiyang3cat
Copy link
Copy Markdown
Contributor

@feiyang3cat feiyang3cat commented May 22, 2026

What changed?

  1. Removed obsolete fields — safe to delete as this feature has not been released (disable compatibility checking temporarily)
  2. Renamed bound to sleep timer to match the previous semantics exposed by the SDK Testing server
  3. Add disable_propagation_for_child to give users a way to stop propagation
  4. Add update_time to UpdateWorkflowExecutionOptionsRequest

Why?

  1. for 1) make the API cleaner
  2. for 2) simplify user experience
  • sleep is a simpler and cleaner concept than bound for user experience and backward compatibility
  1. for 3) a child workflow is a different execution and has its own virtual clock, and users may need an option to change the default propagation behavior
  2. for 4) this can be used when SDK verify the time in TimeSkippingTransitionedEvent match the sleep duration

Breaking changes

  1. removed the feature maxSkippedDuration-> the server has already implemented this feature need to delete the code first
  2. restructured the maxElapsedDurationto sleep-> the server need to do renaming

Server PR
TBD

@feiyang3cat feiyang3cat requested review from a team May 22, 2026 22:14
@feiyang3cat feiyang3cat force-pushed the patch/ts branch 3 times, most recently from 64911c4 to f733324 Compare May 22, 2026 22:42
@feiyang3cat feiyang3cat force-pushed the patch/ts branch 2 times, most recently from 7431f2f to e24f538 Compare June 1, 2026 02:13
@feiyang3cat feiyang3cat changed the title [don't merge] just for review [don't merge] need review and server PR Jun 1, 2026
@feiyang3cat feiyang3cat changed the title [don't merge] need review and server PR [don't merge] time skipping sleep: need review and server PR Jun 1, 2026
@feiyang3cat feiyang3cat force-pushed the patch/ts branch 2 times, most recently from 9ca984a to ae2e298 Compare June 1, 2026 17:10
// setting `enabled` to true via UpdateWorkflowExecutionOptions.
// The current workflow execution is a chain of runs (retries, cron, continue-as-new);
// child workflows are separate executions, so this sleep won't affect them.
google.protobuf.Duration sleep = 2;
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

other names like sleep_timer, timer, timeskipping_timer

Comment thread openapi/openapiv2.json
}
},
"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."
"description": "The configuration for time skipping of a workflow execution (a chain of runs including retries, cron, continue-as-new).\nWhen time skipping is 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; the virtual clock may also skip to the\ntime point of the registered sleep when there is no in-flight work.\n\nFor child workflows, by default, if the parent execution is skipping time, the child execution will also skip time,\nbut the parent's sleep won't affect the child execution. A flag is provided to disable propagation of the\n\"enabled\" flag to child workflows; regardless of that flag, a child workflow inherits the virtual time from the\nparent execution as its start time."
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

"to the time point of the registered sleep" -- does this mean to end point of the sleep period?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

  1. oh I see, this is better expression. yes. will change to "to the end point of the sleep period"

  2. and I think I may need to add another thing is if the workflow execution (the whole chain of runs) completes before having a chance to skip time, the sleep may never take place -> check this example

Comment thread openapi/openapiv2.json
"sleep": {
"type": "string",
"description": "Maximum total virtual time that can be skipped."
"description": "Optionally register a sleep for the current workflow execution.\nWhen the sleep completes, time skipping is disabled and this action is recorded in\nthe WorkflowExecutionTimeSkippingTransitionedEvent, but it can be re-enabled by\nsetting `enabled` to true via UpdateWorkflowExecutionOptions.\nThe current workflow execution is a chain of runs (retries, cron, continue-as-new);\nchild workflows are separate executions, so this sleep won't affect them."
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Is the implication here that the sleep will actually take place, and not be skipped?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

yeah, totally, to be specific sleep counts both natural time passing and time skipping.

for example, the user calls sleep(1h) at 10am, and then the sleep is expected to take place in 11am if the workflow execution hasn't completed. And at 11am (virtual workflow time) the sleep takes place, but for the past 1hour the workflow may takes 30 minutes busy with activities (and this is real 30 minutes), and then waiting for some user timer/condition so we skip 30min(this is skipped) to fire the 1hour.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

let me write some sleep examples

Comment thread openapi/openapiv2.json
"description": "Enables or disables time skipping for this workflow execution."
},
"maxSkippedDuration": {
"sleep": {
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

do you think users might confuse this sleep with sleeps in their actual workflow code?

I was thinking it might be useful to tie this more closely to the skipping? but I see that you're moving away from that!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants