Fixes blockage of Transfer Queue if UpsertSearchAttributes is invoked on a Temporal Server w/o Elastic Search #727
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current implementations of UpsertWorkflowExecution on the Cassandra/SQL visibility persistence stores return a Service Error since Query Operations are not supported for those stores.
The problem is that we do allow customers to invoke UpsertWorkflowExecution successfully even if Elastic Search isn't enabled. This results in our Transfer Task Queues getting clogged because it keeps retrying a persistence operation that will always fail.
The fix is to just have all attempts to UpsertWorkflowExecution on Cassandra/SQL to function as a no-op so that it does not "fail" the transfer task perpetually. We will still fail with explicit errors on List/Scan/Count, so the user should be able to easily tell that their application logic is broken if it does depend on Elastic Search.
The change was verified as follows:
This is a very low risk change.