Support client-side specification of consistency for DescribeWorkflowExecution and GetWorkflowExecutionHistory #6789
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some clients require strong consistency for reads on the DescribeWorkflowExecution and GetWorkflowExecutionHistory rpcs, and are willing to accept the latency trade-off. This adds internal support for endpoints to define a consistency level.
|
Note: Prior discussion was had on the PR here: c-warren#1 |
davidporter-id-au
approved these changes
Apr 5, 2025
timl3136
approved these changes
Apr 5, 2025
abhishekj720
approved these changes
Apr 7, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What changed?
Added (internal) for the
DescribeWorkflowExecutionandGetWorkflowExecutionHistoryRPCs.Why?
The QueryWorkflow RPC already supported defining a consistency level (eventual or strong) to allow consumers to force redirection to the active cluster when strongly consistent reads are required at the cost of latency.
Many customers have requested a similar setup for these additional read APIs. This PR adds support and creates a pattern for adding new APIs in the future.
How did you test it?
Added unit tests at the api and policy layers.
Potential risks
Release notes
No migrations are required.
Documentation Changes
N/A