Adding workflow type name to OrchestratorStartedEvent #23
Conversation
Signed-off-by: Whit Waldo <whit.waldo@innovian.net>
protos/orchestrator_service.proto
Outdated
| // The name of the specific workflow type executed | ||
| optional string workflowTypeName = 1; |
There was a problem hiding this comment.
Please can we rename this to versionName, or ideally, a new WorkflowVersion message with name as a field in that messgae. workflow in the field name is superfluous.
We should not use the word type here as Dapr workflows do not have types- including this would suggest to a user that that we support other workflow definitions beyond the code definition we have today. Type in this context is an implementation detail of some SDKs resolving the workflow version name to a concrete type in that programming language; this is no the case in all languages and indeed not the correct label for the workflow version name. It will not be clear to a business operator observing a workflow what this actually refers to, and will be renamed in the CLI workflow output and UI accordingly.
There was a problem hiding this comment.
I have no qualms with either ask - as far as I'm concerned, this is runtime implementation detail, so I'm happy to defer to your preferences here.
I've pushed this out to a separate message and added some comments for future clarification of purpose that expressly avoid using "type".
Signed-off-by: Whit Waldo <whit.waldo@innovian.net>
| // Contains values used to identify which workflow is executed as part of a versioned operation. | ||
| message WorkflowVersion { | ||
| // The name of the workflow executed as part of this version. | ||
| string name = 1; |
There was a problem hiding this comment.
What are your thoughts in regards storing the version number instead the name? I feel it'll give more freedom to SDKs as versions might not necessarily have a name, but they will for sure have a version number, right?
There was a problem hiding this comment.
No, I don't think that's true. One of the push backs on my proposal was the idea that there would be workflows without a numerical version. For example, a workflow name sufficed by date/time or no numerical component at all, e.g. MyWorkflowOne.
For the purpose of the implementation, we don't need to bother with version numbers at all as that's left as an exercise to the SDK how they want to do it. In .NET, I'm looking at an interface where the developer simply provides an implementation that reflects the "latest" version for any given strategy, whatever approach they want to take to do that. We don't need to increment between versions at all and can just leap from the current to the latest versions.
But we do need to know precisely the name of the workflow run (per the durabletask spec), which this reflects, so I'd encourage not changing this.
There was a problem hiding this comment.
I see, so users will register just the latest version, plus all the previous supported versions. No ordering whatsoever, as that's all we need to know. Fair enough.
We'll need to make sure the version name is human readable, as we'll need to show this value to the user in the CLI (or any kind of workflow visualization tool).
For this I find version numbers more user friendly, for examples this would be a proposed CLI output using version numbers:
TYPE NAME ELAPSED STATUS DETAILS
ExecutionStarted MyWorkflow Ago:48.28s RUNNING
OrchestratorStarted 3.02s RUNNING Version=3
TaskScheduled MyActivity 5.8ms RUNNING Activity=MyActivity
TaskCompleted 4.3ms RUNNING
ExecutionCompleted 1.0ms COMPLETED
And this would be using version names:
TYPE NAME ELAPSED STATUS DETAILS
ExecutionStarted MyWorkflow Ago:48.28s RUNNING
OrchestratorStarted 3.02s RUNNING Version=MyWorkflowThree
TaskScheduled MyActivity 5.8ms RUNNING Activity=MyActivity
TaskCompleted 4.3ms RUNNING
ExecutionCompleted 1.0ms COMPLETED
Not a huge difference I think, but I would prefer version numbers, I find it clearer
There was a problem hiding this comment.
That largely feels like a different proposal, of having some way to store additional metadata about the version. I certainly agree it could be useful, especially as we're adding visibility to the workflows, but that's out of scope of this feature.
Again, workflow type versions (SDK detail, yes) needn't be ordered except to provide some mechanism to surface the "latest" type because when the name of the workflow is sent from the runtime to the SDK, we either need to replay using the provided name in this event from the workflow history or redirect to that "latest" version. Thus, there's no notion of "this one is version 8, but this one is a subsequent version 10". It's just "these workflows are constrained to replaying against MyWorkflow2 and this one against MyWorkflow20251127, and new workflow invocations will run against MyWorkflowRed because it's the latest one".
3 participants
Adds the workflow type name used in an orchestration to the
OrchestratorStartedEventfor type versioning per this proposal.