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