WorkflowContext provides whether the current workflow task is from a reset

[longquanzheng]

Is your feature request related to a problem? Please describe.

It's not possible to know whether or not the current task is from a reset. It would be much simpler to build a logic in workflow to fail on certain case (to stop all the activities), then I will reset it later to resume.

Describe the solution you'd like

Expose a boolean flag in WorkflowContext to indicate whether the current workflow task is from a reset?(basically if the previous task is workflow task failed with reason of Reset)

[cretz]

This is a server-side feature. If this information is deemed important, it will have to be provided on each task in history. Transferring to server repo...

[bergundy]

As discussed internally, the SDK has the information already, it uses it to reseed the RNG.

@longquanzheng, can you show an example of how you'd expect this to be used? A short sample would be nice so we can understand what you have in mind.

Also, what would this flag do if a workflow was reset multiple times?

[longquanzheng]

@longquanzheng, can you show an example of how you'd expect this to be used? A short sample would be nice so we can understand what you have in mind.

Yeah I need to implement a "soft timeout" for a workflow. It will fail the workflow on the timeout. But later on I will let a human to manually restart it by resetting the workflow back to the last workflow task. If I have this boolean, I can just let it create another timer again as an "extended timeout".

This also sounds like a workaround of a missing feature of "soft timeout" that Maxim pointed out. #1412

Also, what would this flag do if a workflow was reset multiple times?

I would expect the flag is only true for the first workflow task after reset. So if a history:

WF task failed by reset
WF task scheduled
WF task started <-- flag will be true
...
WF task scheduled
WF task started <-- flag will be false
...
WF task failed by reset
WF task scheduled
WF task started <-- flag will be true
...
WF task scheduled
WF task started <-- flag will be false
...

[bergundy]

I would recommend that you create a timer and cancel the root workflow scope for a soft timeout for now.
I agree that soft timeout would be a great feature to have in the platform.