-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Open
Labels
Description
Expected Behavior
- A reset operation involves three runs: base run, current run and reset (new) run. If current run is running when processing a reset, it will be terminated. If current run is also a child workflow, then there's a question if it should report to its parent after the termination.
- If current run is base run, then we should not report to parent, as we will have a new run for the child.
- If current run is not base run, then we should report to parent as the new run is not a continuation of the current run.
Actual Behavior
- In the
replyToParentWorkflowlogic, we are checking if the current run is terminated by reset or not, which is not checking if current run is the base run.
We should use the new ResetRunId field in WorkflowExecutionInfo, which is only set when the workflow is the base run of a reset. However, note that with today's event-based replication stack, this ResetRunID field won't be replicated upon reset. So if we switch to that field now, we will temporary make things worse (if failover happens before the closeExecution task is processed) until state-based replication goes live.
To fix the issue before state-based replication, we can:
- Change existing replication logic and instead of generating a historyReplicationTask when workflow is closed, generate a SyncWorkflowState task (yes we have this sync state task in event-based world as well, but only works for closed workflow)
- Add some new fields to the Terminated event to indicate if the workflow is base run.
Steps to Reproduce the Problem
Specifications
- Version:
- Platform:
Reactions are currently unavailable