-
Notifications
You must be signed in to change notification settings - Fork 866
fix(active-active): Fix auto-forwarding for active-active domains #7356
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
if actClSelPolicyForNewWF != nil { | ||
policy.logger.Debug("Active cluster selection policy for new workflow", tag.WorkflowDomainName(domainEntry.GetInfo().Name), tag.OperationName(apiName), tag.Dynamic("policy", actClSelPolicyForNewWF)) | ||
activeClusterInfo, err := policy.activeClusterManager.GetActiveClusterInfoByClusterAttribute(ctx, domainEntry.GetInfo().ID, actClSelPolicyForNewWF.GetClusterAttribute()) | ||
if apiName == "SignalWithStartWorkflowExecution" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Switching on API name/string raises some red flags for me. I know they should be static and shouldn't change - but a change to the way we generate our APIs would cause a breaking change here.
Is there a way we could implement the logic without knowing which API is calling it? Perhaps just from the information we have in the non-api name parameters? Previously it was only used for logging tags.
e.g if the actClSelPolicyForNewWF
is not nil we could always check for an an existing policy (as that covers the signalwithstart case as well).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about a switch block which panics on fallthrough / default to ensure that we catch these failures noisily on refactor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that would make it easier to track, but I'm not concerned about the refactor as much as I am maintaining this in a couple years when we try to change our proto gen, or someone copying this pattern elsewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It has to know the API name, because actClSelPolicyForNewWF
can be empty for StartWorkflow and SignalWithStartWorkflow API. And the forwarding rules are API-based. The function needs to need the APIs directly or indirectly.
What changed?
Why?
Bug fix
How did you test it?
unit tests && simulation tests
Potential risks
Release notes
Documentation Changes