Workflow ID Collision Errors

Community Support
,
1

I’m currently referencing the workflow id section of the docs and it states that attempting to spawn a second workflow with the same workflow ID will result in an error. I am attempting to extract that error, but I’m not actually receiving it.

This is the exact code I’m using:

we, err := temporalClient.ExecuteWorkflow(context.Background(), workflowOptions, temporal.CompleteAssetDrop, params)
if err != nil {
	c.AbortWithStatusJSON(http.StatusConflict, err.Error())
	return
}

The workflow isn’t spawning a second time and the original isn’t being disrupted, but I’m also not hitting the error block.

Am I missing something and is this the intended behavior? Also how should I be checking for ID collision if this is not a valid strategy?

Thanks in advance!

2

Look at the error from we.Get(...).

3

I’d like to run the workflow asynchronously, so calling we.Get() would block program execution.

Would calling QueryWorkflow(…) let me check if that particular execution attempt worked?

4

I read a little further into the docs, and I believe that my best bet here is to call DescribeWorkflowExecution(…) prior to executing the workflow. Here I can check if the ID is attached to a running workflow. This does introduce a very tiny race condition, but I believe I’m willing to live with it.

If there is a better solution here, I would love to hear it though!

5

No, calling DescribeWorkflowExecution is not going to help as it decreases performance and has an inherent race condition with the start call.

The solution is to set StartWorkflowOptions.WorkflowExecutionErrorWhenAlreadyStarted to true.

6

Wow, can’t believe I overlooked this! Thank you!