I’ve been thinking around ways to help ensure smooth transitions between deployments where there are changes to a workflow.
I was wondering if there were any downsides to versioning the workflow TaskQueue such that each new deployment would get an updated task queue name.
My thinking is that when a new deployment occurs, all new requests would be talking to the new fleet that is compatible with the latest code changes since they would be registered to the new task queue name.
The previous deployment could stay active for a defined duration to catch any outlier workflows that are might still be processing, before being safely removed.
If my understanding is correct, since there would be different task queue names for each, this minimizes the risk of the different workflow code interacting with one another.
So i guess i’m wondering if my thinking here is off base, or if this might be a viable strategy?
The different task queue name per version approach works. The main drawback that you need to maintain a worker pool per version for the duration of the longest workflow. For long running workflows this becomes hard to manage and consumes a lot of resources. Another problem is that it is not possible to fix a bug in already running workflow.
The recommended way to do versioning is to use Workflow.getVersion (or workflow.GetVersion in Go SDK) API. This API allows changing workflow code in a backwards compatible manner. Then you can have any number of versions running from the same worker. It also supports updating code while workflows are running. So fixing bugs for already started workflows is supported.