automatic time-skipping by feiyang3cat · Pull Request #740 · temporalio/api

feiyang3cat · 2026-03-23T22:25:35Z

What changed?
new feature: automatic time-skipping configuration and new event type added

Breaking changes
new event type added but right now no workflow history will have this new event type

Server PR
not expect to break server, no new rpc-handler and new fields are all optional

feiyang3cat · 2026-03-23T22:36:31Z

temporal/api/workflow/v1/message.proto

+message TimeSkippingConfig {
+
+    // If set, enables automatic time-skipping for this workflow execution.
+    // It can also be disabled by setting this field to false.


@Sushisource Hey! I've cleaned this pr and ready for review.

And this config may need special attention since it is changed significantly from previous version Chad proposed.
(1)deleted most of the fine-grained control (like max timer-firing count, max duration to skip) from the previous version. The reason is it is ambiguous when complicated configuration is propagated to child-workflows.
(2) I have also changed the nested config to one single layer because this configuration is only used for automatic time-skipping, manual time-skipping will have a separate request and response payload
(3) we allow disabling time-skipping for in-flight workflows since it is not hard for the server to have this feature, and it will be a nice-to-have feature same as the SDK TestServer.

I think we can consider wrapping up this pr early, and put manual time-skipping in a separate pr maybe.
Pls feel free to disagree, happy to refine.

I think this looks totally reasonable - but I also don't see any reason to rush the PR while work is in progress unless we intend to ship a version without manual skipping first. If we don't, let's use the opportunity to develop it and decide if we want to make any changes to this config that relate to manual timeskipping.

temporal/api/workflow/v1/message.proto

Sushisource · 2026-03-24T18:55:30Z

temporal/api/workflow/v1/message.proto

+message TimeSkippingConfig {
+
+    // If set, enables automatic time-skipping for this workflow execution.
+    // It can also be disabled by setting this field to false.


I think this looks totally reasonable - but I also don't see any reason to rush the PR while work is in progress unless we intend to ship a version without manual skipping first. If we don't, let's use the opportunity to develop it and decide if we want to make any changes to this config that relate to manual timeskipping.

temporal/api/history/v1/message.proto

Sushisource · 2026-03-26T20:15:27Z

temporal/api/enums/v1/event_type.proto

    // An event that indicates that the previously paused workflow execution has been unpaused.
    EVENT_TYPE_WORKFLOW_EXECUTION_UNPAUSED = 59;
+    // An event that indicates that some duration was skipped for this workflow execution.
+    EVENT_TYPE_WORKFLOW_EXECUTION_TIME_SKIPPED = 60;


You know this just occurred to me and I don't think we've talked about it - if time skipping is enabled on a workflow with an old SDK version processing it, it's going to break on these new event types.

That's fine I think, we will tell people they need to upgrade, but we need to make sure that is clear in the docs & GTM material we create.

get it. the docs & GTM material mainly refer to API comments (here) and https://docs.temporal.io/ ?

if we always set worker_may_ignore for TimeSkippingEvents, it won't break workers right? because in the demo, I set worker_may_ignore = true and used current SDK which has no time-skipping feature and didnt break it

I think for sdk version old enough, it doesn't even know about the worker_may_ignore flag, hence the comment. but yeah this is a new feature so we can make it clear re. the sdk version required.

Sushisource · 2026-03-26T20:18:03Z

temporal/api/history/v1/message.proto

+    // when true, it means the automatic time-skipping was enabled with a bound 
+    // and now the bound is reached and the time-skipping is disabled automatically.
+    bool bound_reached_and_time_skipping_disabled = 2;


Suggested change

// when true, it means the automatic time-skipping was enabled with a bound

// and now the bound is reached and the time-skipping is disabled automatically.

bool bound_reached_and_time_skipping_disabled = 2;

// when true, automatic time-skipping was enabled with a bound

// and now that bound has been reached and time-skipping is disabled automatically.

bool disabled_after_bound = 2;

This is my best idea for a better name. The comment makes things clear, so I don't think we need a super wordy field name.

temporal/api/workflow/v1/message.proto

feiyang3cat · 2026-04-01T17:16:55Z

temporal/api/history/v1/message.proto

    string request_id = 3;
 }

+// Attributes for an event indicating that virtual time was advanced for a workflow execution,


⭐ highlight the change after review meeting

We should also add to the comment here that worker_may_ignore should always be set true for this event

api/temporal/api/history/v1/message.proto

Line 1127 in 2547d30

bool worker_may_ignore = 300;

added but I remember an early proposal was to break the workers and remind them to upgrade. So I guess our strategy changed?

Sorry, I meant we should add this to the comment here, not on the field. Otherwise that field will have an ever-increasing list in the comment.

And I think that was before we realized workers don't need to handle this at all. Even old SDKs will be able to successfully replay histories with time-skipping, which could be useful if users want to try this without needing to upgrade SDKs.

I guess I located here correctly this time?

It should be on this message, yeah, I don't see it here yet though?

tagged you there

temporal/api/workflow/v1/message.proto

Sushisource · 2026-04-01T17:20:57Z

temporal/api/history/v1/message.proto

    string request_id = 3;
 }

+// Attributes for an event indicating that virtual time was advanced for a workflow execution,


We should also add to the comment here that worker_may_ignore should always be set true for this event

api/temporal/api/history/v1/message.proto

Line 1127 in 2547d30

bool worker_may_ignore = 300;

temporal/api/workflow/v1/message.proto

yycptt · 2026-04-01T21:48:21Z

temporal/api/enums/v1/event_type.proto

    // An event that indicates that the previously paused workflow execution has been unpaused.
    EVENT_TYPE_WORKFLOW_EXECUTION_UNPAUSED = 59;
+    // An event that indicates that some duration was skipped for this workflow execution.
+    EVENT_TYPE_WORKFLOW_EXECUTION_TIME_SKIPPED = 60;


I think for sdk version old enough, it doesn't even know about the worker_may_ignore flag, hence the comment. but yeah this is a new feature so we can make it clear re. the sdk version required.

temporal/api/history/v1/message.proto

yycptt · 2026-04-01T22:09:14Z

temporal/api/workflow/v1/message.proto

+    // If set, the enabled field is not propagated to child workflows.
+    bool disable_propagation = 2;


should clarify if this will propagate via continue as new or reset as well.

I am thinking we make it simple now: we don't propagate bound and propagate enable for all these three cases. And this feature is not supported for nexus operation so no propagation for now. make sense?

yeah that make sense. Just want to make sure ^ is in the comment.

yycptt · 2026-04-01T22:11:43Z

temporal/api/workflowservice/v1/request_response.proto


 message DeleteActivityExecutionResponse {
-}
+}


nit: add new line

emm it seems not to be a new line >?

not sure i follow. it means a newline char is removed at file end. not something critical.

yycptt · 2026-04-01T22:12:42Z

temporal/api/workflow/v1/message.proto

+// Configuration for automatic time skipping during a workflow execution.
+// When enabled, virtual time advances automatically whenever there are
+// no in-flight activities, child workflows, or Nexus operations.
+message TimeSkippingConfig {


do we need to add this in to child workflow command?

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.

no strong opinion either way given we support time skipping config propagation. Please track the potential work item somewhere though.

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.

temporal/api/workflow/v1/message.proto

temporal/api/history/v1/message.proto

temporal/api/workflow/v1/message.proto

…pping, and change event name

yycptt · 2026-04-03T19:28:00Z

temporal/api/workflow/v1/message.proto

+message TimeSkippingConfig {
+
+    // 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) 


Suggested change

// By default, this field is propagated to transitively related workflows (child workflows/start-as-new/reset)

// By default, this field is propagated to transitively related workflows (child workflows/continue-as-new/reset)

yycptt · 2026-04-03T19:32:01Z

temporal/api/enums/v1/event_type.proto

    // An event that indicates that the previously paused workflow execution has been unpaused.
    EVENT_TYPE_WORKFLOW_EXECUTION_UNPAUSED = 59;
+    // An event that indicates time skipping advanced time or was disabled automatically after a bound was reached.
+    EVENT_TYPE_WORKFLOW_EXECUTION_TIME_SKIPPING_STATE_CHANGED = 60;


The name TIME_SKIPPING_STATE_CHANGED makes me feel there this should the event upon enabling time skipping as well, but instead it will be WorkflowExecutionOptionsUpdated.

I actually don't have strong opinion re. if we need to have an event when time skipping is disabled but there's no actual time skipping occurred, so the old timeSkipped event name works for me as well.

feiyang3cat requested review from a team as code owners March 23, 2026 22:25

feiyang3cat changed the title ~~POC automatic timeskipping~~ automatic time-skipping Mar 23, 2026

feiyang3cat commented Mar 23, 2026

View reviewed changes

feiyang3cat requested review from Sushisource and yycptt March 23, 2026 22:37

feiyang3cat force-pushed the api-time-skipping-v2 branch 3 times, most recently from 83f6639 to e1e1c03 Compare March 23, 2026 23:23

feiyang3cat mentioned this pull request Mar 24, 2026

automatic time-skipping (don't merge, will split into smaller prs) temporalio/temporal#9617

Open

5 tasks

Sushisource reviewed Mar 24, 2026

View reviewed changes

feiyang3cat changed the title ~~automatic time-skipping~~ automatic time-skipping (don't merge) Mar 24, 2026

feiyang3cat force-pushed the api-time-skipping-v2 branch 8 times, most recently from 9721ff7 to c686992 Compare March 26, 2026 03:53

feiyang3cat commented Mar 26, 2026

View reviewed changes

temporal/api/history/v1/message.proto Outdated Show resolved Hide resolved

Sushisource reviewed Mar 26, 2026

View reviewed changes

feiyang3cat force-pushed the api-time-skipping-v2 branch 2 times, most recently from 837c381 to 012f767 Compare March 27, 2026 19:59

feiyang3cat commented Mar 27, 2026

View reviewed changes

temporal/api/workflow/v1/message.proto Show resolved Hide resolved

feiyang3cat changed the title ~~automatic time-skipping (don't merge)~~ automatic time-skipping Mar 30, 2026

feiyang3cat commented Apr 1, 2026

View reviewed changes

temporal/api/workflow/v1/message.proto Show resolved Hide resolved

Sushisource reviewed Apr 1, 2026

View reviewed changes

feiyang3cat enabled auto-merge (squash) April 1, 2026 18:04

yycptt reviewed Apr 1, 2026

View reviewed changes

temporal/api/workflow/v1/message.proto Outdated Show resolved Hide resolved

feiyang3cat commented Apr 2, 2026

View reviewed changes

temporal/api/history/v1/message.proto Show resolved Hide resolved

feiyang3cat added 5 commits April 2, 2026 16:12

api for automatic timeskipping

b466ee4

add fine-grained control to automatic timeskipping

858f4cc

refine time-skipping related comments and fields

a31e53a

refine comments for time-skipping

5314116

refine comments of TimeSkippingConfig

cabd8ee

feiyang3cat force-pushed the api-time-skipping-v2 branch from 525ec42 to cabd8ee Compare April 2, 2026 23:12

feiyang3cat commented Apr 2, 2026

View reviewed changes

temporal/api/workflow/v1/message.proto Show resolved Hide resolved

feiyang3cat force-pushed the api-time-skipping-v2 branch 8 times, most recently from ac4dd6b to 2bf473b Compare April 3, 2026 02:21

add detailed explanation of in-flight work which will impact time-ski…

9da7862

…pping, and change event name

feiyang3cat force-pushed the api-time-skipping-v2 branch from 2bf473b to 9da7862 Compare April 3, 2026 02:22

yycptt reviewed Apr 3, 2026

View reviewed changes

		// If set, the enabled field is not propagated to child workflows.
		bool disable_propagation = 2;

	// By default, this field is propagated to transitively related workflows (child workflows/start-as-new/reset)
	// By default, this field is propagated to transitively related workflows (child workflows/continue-as-new/reset)

Conversation

feiyang3cat commented Mar 23, 2026

Uh oh!

feiyang3cat Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

feiyang3cat Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

feiyang3cat Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

feiyang3cat Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

feiyang3cat Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yycptt Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

feiyang3cat Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

feiyang3cat Mar 23, 2026 •

edited

Loading

feiyang3cat Apr 1, 2026 •

edited

Loading

feiyang3cat Apr 1, 2026 •

edited

Loading

feiyang3cat Apr 1, 2026 •

edited

Loading

feiyang3cat Apr 1, 2026 •

edited

Loading

yycptt Apr 1, 2026 •

edited

Loading

feiyang3cat Apr 2, 2026 •

edited

Loading