You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
The text was updated successfully, but these errors were encountered:
Expected Behavior
Actual Behavior
replyToParentWorkflow
logic, 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:
Steps to Reproduce the Problem
Specifications
The text was updated successfully, but these errors were encountered: