Skip to content

Adding workflow type name to OrchestratorStartedEvent #23

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Adding workflow type name to OrchestratorStartedEvent #23

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
9ca415e
Adding workflow type name to OrchestratorStartedEvent
WhitWaldo Nov 25, 2025
49f48a5
Renamed per request
WhitWaldo Nov 25, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 8 additions & 1 deletion protos/orchestrator_service.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -161,8 +161,15 @@ message TimerFiredEvent {
int32 timerId = 2;
}

// 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;
Copy link
Member

@acroca acroca Nov 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Author

@WhitWaldo WhitWaldo Nov 26, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@acroca acroca Nov 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

@WhitWaldo WhitWaldo Nov 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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".

}

message OrchestratorStartedEvent {
// No payload data
// Optionally identifies the workflow executed as part of a versioned operation.
optional WorkflowVersion Version = 1;
}

message OrchestratorCompletedEvent {
Expand Down