6032
}
6033
6034
>
if !proto.Equal(ms.GetEffectiveDeployment(), previousEffectiveDeployment) ||
mutable_state_impl.go
6035
>
ms.GetEffectiveVersioningBehavior() != previousEffectiveVersioningBehavior {
6036
>
// TODO (carly) part 2: if safe mode, do replay test on new deployment if deployment changed, if fail, revert changes and abort
6037
>
// If there is an ongoing transition, we remove it so that tasks from this workflow (including the pending WFT
6038
>
// that initiated the transition) can run on our override deployment as soon as possible.
6039
>
//
6040
>
// We only have to think about the case where the workflow is unpinned, since if the workflow is pinned, no
6041
>
// transition will start.
6042
>
//
6043
>
// If we did NOT remove the transition, we would have to keep the pending WFT scheduled per the transition's
6044
>
// deployment, so that when the task is started it can run on the transition's target deployment, complete,
6045
>
// and thereby complete the transition. If there is anything wrong with the transition's target deployment,
6046
>
// the transition could hang due to the task being stuck, or the transition could fail if the WFT fails.
6047
>
// Basically, WF might be stuck in a transition loop, and user wants to pin it to the previous build to move
6048
>
// it out of the loop. If we don't remove the transition, it will still be stuck.
6049
>
//
6050
>
// It is possible for there to be an ongoing transition and an override that both result in the same effective
6051
>
// behavior and effective deployment. In that case, we would not hit the code path to remove the transition or
6052
>
// reschedule the WFT. For this to happen, the existing behavior and the override would both have to be unpinned.
6053
>
// If we don't remove the transition or reschedule pending tasks, the outstanding WFT on the transition's
6054
>
// target queue will be started on the transition's target deployment. Most likely this matches user's intention
6055
>
// because they add the unpinned override, they want to workflow to do the transition. Even if we removed the
6056
>
// transition, the rescheduled task will be redirected by Matching to the old transition's deployment again,
6057
>
// and it will start the same transition in the workflow. So removing the transition would not make a difference
6058
>
// and would in fact add some extra work for the server.
6059
>
ms.executionInfo.GetVersioningInfo().DeploymentTransition = nil
6060
>
ms.executionInfo.GetVersioningInfo().VersionTransition = nil
6061
>
6062
>
// If effective deployment or behavior change, we need to reschedule any pending tasks, because History will reject
6063
>
// the task's start request if the task is being started by a poller that is not from the workflow's effective
6064
>
// deployment according to History. Therefore, it is important for matching to match tasks with the correct pollers.
6065
>
// Even if the effective deployment does not change, we still need to reschedule tasks into the appropriate
6066
>
// default/unpinned queue or the pinned queue, because the two queues will be handled differently if the task queue's
6067
>
// Current Deployment changes between now and when the task is started.
6068
>
//
6069
>
// We choose to let any started WFT that is running on the old deployment finish running, instead of forcing it to fail.
6070
>
requestReschedulePendingWorkflowTask = true
6071
>
ms.ClearStickyTaskQueue()
6072
>
6073
>
// For v3 versioned workflows (ms.GetEffectiveVersioningBehavior() != UNSPECIFIED), this will update the reachability
6074
>
// search attribute based on the execution_info.deployment and/or override deployment if one exists.
6075
>
limit := ms.config.SearchAttributesSizeOfValueLimit(ms.namespaceEntry.Name().String())
6076
>
// Passing nil useVersion because an override by itself should not add to used versions SA
6077
>
if err := ms.updateBuildIdsAndDeploymentSearchAttributes(nil, nil, limit); err != nil {
6078
return requestReschedulePendingWorkflowTask, err
6079
}
6080
}
6081
6082
>
return requestReschedulePendingWorkflowTask, ms.reschedulePendingActivities(0)
mutable_state_impl.go
6083
}
6084