-
Notifications
You must be signed in to change notification settings - Fork 69
Async SetRampingVersion and SetCurrentVersion #575
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
base: versioning-3.2
Are you sure you want to change the base?
Conversation
@@ -201,6 +201,10 @@ message WorkerDeploymentInfo { | |||
|
|||
RoutingConfig routing_config = 4; | |||
|
|||
// Indicates whether the routing_config has been fully propagated to all | |||
// relevant task queues and partitions. | |||
enums.v1.TaskQueuePropagation routing_config_propagation_state = 6; |
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 wonder if even saying "task queue" and "propagation" is too much detail / too specific? Maybe something like "update state": "pending" or "completed"
@@ -201,6 +201,10 @@ message WorkerDeploymentInfo { | |||
|
|||
RoutingConfig routing_config = 4; | |||
|
|||
// Indicates whether the routing_config has been fully propagated to all | |||
// relevant task queues and partitions. | |||
enums.v1.TaskQueuePropagation routing_config_propagation_state = 6; |
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.
routing_config_propagation_state
is something that's related to the routing information of a worker deployment info and I wonder if it's better suited to be present inside routing_config
?
READ BEFORE MERGING: All PRs require approval by both Server AND SDK teams before merging! This is why the number of required approvals is "2" and not "1"--two reviewers from the same team is NOT sufficient. If your PR is not approved by someone in BOTH teams, it may be summarily reverted.
Synchronous task queue propagation meant that the lock on the Worker Deployment Manager was held for many seconds, meaning the APIs would be unavailable if there were large numbers of partitions. This allows us to have high availability APIs while being transparent about where tasks are being routed.
Breaking changes
Server PR