Conversation
| message TimeSkippingConfig { | ||
|
|
||
| // If set, enables automatic time-skipping for this workflow execution. | ||
| // It can also be disabled by setting this field to false. |
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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.
feiyang3cat
force-pushed
the
api-time-skipping-v2
branch
3 times, most recently
from
83f6639 to
e1e1c03
Compare
| message TimeSkippingConfig { | ||
|
|
||
| // If set, enables automatic time-skipping for this workflow execution. | ||
| // It can also be disabled by setting this field to false. |
There was a problem hiding this comment.
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.
feiyang3cat
changed the title
feiyang3cat
force-pushed
the
api-time-skipping-v2
branch
2 times, most recently
from
4aeceb6 to
094e2c5
Compare
feiyang3cat
force-pushed
the
api-time-skipping-v2
branch
6 times, most recently
from
9721ff7 to
c686992
Compare
| // 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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
get it. the docs & GTM material mainly refer to API comments (here) and https://docs.temporal.io/ ?
| // 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; |
There was a problem hiding this comment.
| // 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.
feiyang3cat
force-pushed
the
api-time-skipping-v2
branch
from
c686992 to
837c381
Compare
feiyang3cat
force-pushed
the
api-time-skipping-v2
branch
from
837c381 to
012f767
Compare
| // i.e. the existing time-skipping conf will be preserved. | ||
| TimeSkippingConfig time_skipping_config = 3; | ||
| } | ||
|
|
There was a problem hiding this comment.
@Sushisource @yycptt updated this part especially the bound part according to discussions. With the new fine-grained bound, I think the 1h-signal can be easily implemented by setting max_elapsed_duration to 1hour or max_target_time to some specific time in 1h hour.
For server, a EVENT_TYPE_WORKFLOW_EXECUTION_TIME_SKIPPED will be created to indicate time-skipping is disabled by bound even if no duration skipped.
For SDK can poll this event, but I think there are two things to consider right now
- we may need to add a version/ID for the time-skipping config if the user resets this config multiple times so the poller can differentiate EVENT_TYPE_WORKFLOW_EXECUTION_TIME_SKIPPED easily
- right now there is one get-api to read history events, it may be easier if we build a dedicated polling api (but this one may be added later?
feiyang3cat
changed the title
2 participants
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