Add VersioningBehaviorOverride to StartWorkflowExecutionRequest #477
Conversation
| @@ -201,6 +201,9 @@ message StartWorkflowExecutionRequest { | |||
| temporal.api.sdk.v1.UserMetadata user_metadata = 23; | |||
| // Links to be associated with the workflow. | |||
| repeated temporal.api.common.v1.Link links = 24; | |||
| // If set, takes precedence over the Versioning Behavior sent by the SDK on Workflow Task completion. | |||
| // To unset the override after the workflow is running, use UpdateWorkflowExecutionOptions. | |||
| temporal.api.common.v1.VersioningBehaviorOverride versioning_behavior_override = 25; | |||
There was a problem hiding this comment.
Does this need to also be added to SignalWithStartWorkflowExecutionRequest for signal with start and NewWorkflowExecutionInfo for schedules?
There was a problem hiding this comment.
This is primarily to enable customers to write canary workflows and start/run them on a specific worker deployment that they want to test. I could see people wanting to do that with schedules, not sure if people would want to do that with SignalWithStart, but there's no harm in giving them the option
There was a problem hiding this comment.
I just added it to both of those
There was a problem hiding this comment.
I think it will also need to be added to internal.StartWorkflowOptions in sdk-go
There was a problem hiding this comment.
From an SDK POV, probably to every start workflow options in every language (Go is not more important than the others)
|
One thing about error handling. The override specifies a deployment and a build id. We also pass the task queue name when starting a workflow. Is there any check in the server that the task queue belongs to the deployment? Maybe the answer is no check and the workflow times out, but a comment on this would be useful... |
@antlai-temporal - asking just to ensure we are on the same page - you specifically mean using the override during an update to get out of bad situations right? I think care should be taken on the server side and we will have a check to verify that the task-queue is in the right deployment before we do move it out and place it into a different one |
No, this API is to start a new workflow on a particular deployment. When you start a workflow you also need to specify the task queue. The question is if we make a mistake the deployment may not include that queue. Since task queue membership in a deployment is eventually consistent (triggered by worker polling), we may not want to throw an error, and wait until the workflow timeout... |
Correct. This is possible for pinned overrides. If they pinned to the wrong deployment its like starting the wf on a non-existing task queue. We assume user knows what they are doing. In UI we'll show a watning that "there is no poller for this TQ + deployment". |
|
@carlydf I think you should add the override to |
Add VersioningBehaviorOverride to StartWorkflowExecutionRequest
So that users can implement their own deployment checks by sending a test workflow to a specific deployment, before ramping traffic on that deployment.
Breaking changes
Server PR