WorkflowId as a locking semantic

Community Support
,
1

Apologies. I am not actually sure this even requires an answer . . .

A useful workflow capability is that the workflowId has to be unique to a namespace. This is useful as you can use it as a simple locking mechanism on an operation.

The challenge is that the workflowId is set externally to the workflow, by the caller.

Ideally, it would be nice if a workflow had the capability to set the workflowId based on it’s input. I can see an argument for inefficiency, as it means at least one task round-trip…

A workaround is to have an outer workflow (e.g. with a random UUID for a workflowId) which determines the correct workflowId (used for locking semantics) which calls an inner workflow with that workflowId. The downside is obviously – it’s another workflow. It’s also boilerplate.

The question then becomes: why are you locking? If the workflow creation fails, you’re forcing the caller to retry. A solution to that would to use a queue instead. Queues, if I’m not mistaken, aren’t fully supported yet (the API exists in “beta” – unless that changed in a recent SDK release). Though, we’re using them anyway. :wink:

So I’m wondering, could we reduce the boilerplate around queues in this case? The problem then is – what if you have queue, yet processing doesn’t have to be strictly sequential?

Sean

2

Using workflow input to generate workflow ID is a useful abstraction. But it is a pretty intrusive change as it requires invocation of an application specific code before a workflow instance is created. Adding queue is not going to help here as the queue consumer still has to be invoked to start a workflow setting the workflow ID appropriately.

We’ll keep this requirement in mind when thinking about the next generation of Temporal APIs.

3

As the input must be known on creation, you can serialize this input, crypto-hash the bytes (e.g. with sha256.Sum) and use this as the workflow id. It’s thus fully under client control, is reproducible and needs no change at the temporal server side. The probability of collisions is normally much lower than some high energy particle flipping a bit in RAM.