temporalio
Add Activity support for Worker Versioning
Is your feature request related to a problem? Please describe. My team has Workflows and Activities developed on different release cycles. We use Worker Versioning to either pin or use latest version of a Workflow. However, when a Workflow calls an Activity, even if the Activity Worker uses Worker Versioning, there is no way for the Workflow to specify the version of the Activity to use. We have resorted to baking the Activity version into the task queue name, which is not ideal as our Workers are already using Deployments and Versioning.
Describe the solution you'd like
Add versioningOverride to ActivityOptions, and have the Temporal Service use the versioningOverride (as well as the worker defaults specified in WorkerDeploymentOptions) to resolve the scheduled Activity to a Worker Deployment.
Describe alternatives you've considered For now, we are baking the Activity Version into the task queue name, which forces all Activity calls to be pinned to a specific version.
Additional context This would mostly leverage the work already done for Workflow Versioning.
@jbrody-nexxa I'd like to understand more about your use case.
My team has Workflows and Activities developed on different release cycles.
In this case, first thing I'd think is "workflow <-> activity interface should remain compatible across versions of these separate deployments" so, for example, when you upgrade the workflow worker, both old and new workflow workers can work with the current activity worker version (and vice versa).
I assume something is preventing you from taking that approach. Can I know what it is?
Generally, during the design of this feature we've been trying to not involve the caller in worker versioning (and deployment cycles of the workers) and it's up to the user needs to keep the interface compatible. But I don't think there is any big reason preventing us to add this feature if there are compelling use cases for it.
In this case, first thing I'd think is "workflow <-> activity interface should remain compatible across versions of these separate deployments" so, for example, when you upgrade the workflow worker, both old and new workflow workers can work with the current activity worker version (and vice versa).
I assume something is preventing you from taking that approach. Can I know what it is?
Sure, if you can be 100% confident that the interface (and any external side effects of the implementation) will never change, you could take this approach. I would say about 90% of the time, that's not the case for us. Interfaces do change, and even when they don't, sometimes implementations change in a way that has external side effects. In those cases, we want to increment a version and make sure the calling workflow is intentionally upgrading to it. Of course, one could achieve the same outcome by changing the activity name rather than versioning it. Effectively, that's what we've done by baking the version number into the activity task queue. But that's not activity versioning.
If you think of an activity the same as a block of code or a library, you could ask the same of any other code or library... why doesn't npm or maven or a REST API simply always serve up the latest version and rely on the implementation to guarantee backwards compatibility? Because in practice things do change, and if the framework doesn't support versioning, it means you'll end up with a proliferation of artifacts when the implementation inevitably does change.
Generally, during the design of this feature we've been trying to not involve the caller in worker versioning (and deployment cycles of the workers) and it's up to the user needs to keep the interface compatible. But I don't think there is any big reason preventing us to add this feature if there are compelling use cases for it.
This is surprising to hear because the workflow client has the ability to specify the version and strategy (pinned, auto-upgrade) when calling a workflow. This works great for us, as we explicitly version workflows and workflow dependencies due to the reasons above. All we need is the same interface between workflows and activities, for the same reasons.
@jbrody-nexxa we discussed this internally. We want to support it, but it is right now in backlog behind some other more important items.