I’m currently starting to play around and evaluate Temporal. I went through the docs, the glossary, and some guides/tutorials. No major issues so far, except that I fundamentally don’t understand what a Workflow ID represents.
I initially thought a Workflow ID was the ID of a workflow execution. But that’s in fact what a Run ID is. Moreover, several executions may share the same Workflow ID so that’s not it.
Then I thought a Workflow ID was meant to identity the Workflow definition. But that’s not it either. Workflow definition is called the Workflow type.
So at this point, all I know is that a Workflow ID is something defined by the application when starting a Workflow, and that you can have only one workflow execution open with a given Workflow ID at the same time. But it still doesn’t tell me what a Workflow ID is, conceptually. Please help me understand
You can think about WorkflowID as a uniqueness constraint. Only one workflow at a time with the given ID can be open. When you start a new workflow, you can control how to deal with closed workflows that share the same ID. See WorkflowIdReusePolicy. ID is also used to send external signals, updates, or queries to a workflow.
Look at a simple scenario. Imagine that a workflow failed. How do you request its reexecution if you cannot reuse the same WorkflowID? But if it is reexecuted how do you differentiate between different executions? That’s why runID is needed.
Thanks for the explanation. In case of multiple executions caused by failures and retries, I can see how workflowID can be used to logically group these executions together. For this kind of scenario, the “Allow duplicate failed only” policy is enough I believe.
Are there other scenarios (not involving retries) where it would make sense to re-use a WorkflowID? Now I’m trying to understand why one would want to use the “Allow duplicate” policy.
There are many scenarios when you want to ensure that only one workflow mutates some resource. But after a workflow is completed, it is OK to start another mutation.
Another scenario is continue-as-new, which is needed to keep history size bounded.
In my setup I’m using some external unique identifiers as part of a workflow ID. Example: message/thread ID I’m reading from gmail. In some cases I have one workflow that has to just be there — a single dumb workflow ID is created manually (“pollGmail”), it will schedule further work.
Another use-case: CRM-like scenario (customer.io like behaviour) where I’d use customer ID/email as part of the workflow ID and would use signalWithStart instead of a regular start. So in that case each workflow with an ID is kind of an actor.
