mirror of
https://github.com/hanzoai/tasks.git
synced 2026-10-04 02:04:03 +00:00
2ac6a4a29a
## What changed? - The following APIs now propagate Worker Deployment Routing Config to the Task Queues in an async manner. This means that the API will return if the update is valid but the routing behavior fully adjusts in an eventually consistent manner. - `SetCurrentWorkerDeploymentVersion` - `SetRampingWorkerDeploymentVersion` - `DeleteDeploymentVersion` - `DescribeWorkerDeployment` now returns a `RoutingConfigUpdateState` enum to inform the user if the propagation is fully done. (usable for writing unflaky test) - RoutingConfig now has `revision_number` which tracks changes in the config. All task queues now receive the routing info and the revision number. (used for handling versioning race conditions) - ## Why? The Routing Config info propagation to the task queues and their partitions can take mentioned APIs can take long when there are many task queues (and/or partitions) which could cause to client side timeouts that would be hard to trouble shoot for users. Also, the Worker Deployment would be locked during the update procedure in the old logic which would make all other APIs non-responsive. ## How did you test it? - [ ] built - [ ] run locally and tested manually - [x] covered by existing tests - [x] added new unit test(s) - [x] added new functional test(s) ## Potential risks This is a breaking change to the API behavior in the sense that the affected APIs are now eventually consistent and may return before all the task queue receive the changes. This should be OK for practical use but if some one is writing tests for their deployment system they'd need to wait on the `RoutingConfigUpdateState` to become `COMPLETED` before proceeding with the test. --------- Co-authored-by: Shivam Saraf <[email protected]>