Should we be using suffix here?

Let's give this a more specific name, like CreateWorkflowInstanceRequest

For consistency with existing code, I suggest StartEventData.

This goes back to my comment on the durabletask-go repo, but I don't think we need to expose a BuildStatusSet utility function for this simple purpose. I think a simple for-loop over reuseIDPolicy.GetOperationStatus() and comparing to runtimeStatus on each loop iteration is good enough since we only have a small number of possible status values. This might even be more performant than creating a map and doing hashing operations for the key lookup.

I'm a little confused about the function name here. It's called createInstance but the only thing it does is create a reminder? Can we give this a more specific name, like scheduleWorkflowStart?

We've already loaded the runtime state in createWorkflowInstance. Should we reuse that and pass it as a parameter rather than getting the runtime state again?

This requires a change in durabletask-go, but I wonder if we should prefix these constants with RUNTIME_STATUS_ so that it's clear what these values are for.

Can't we just use the existing runtimeStatus.IsCompleted() for this instead of checking specific status values? That would be more maintainable.

The reason I am not using runtimeStatus.IsCompleted() is that I am not quite sure if it equals [COMPLETED , TERMINATED , FAILED]. From the code, the completedEvent is assigned when the orchestration completed at https://github.com/microsoft/durabletask-go/blob/aa335e20a192395649eb9ede97b57c9f647238ea/backend/runtimestate.go#L134, but when orchestration is terminated we don't assign a completedEvent, instead we create a ExecutionTerminatedEvent at https://github.com/microsoft/durabletask-go/blob/aa335e20a192395649eb9ede97b57c9f647238ea/backend/runtimestate.go#L197, so it seems runtimeStatus.IsCompleted() only check if orchestration is completed but not check if it's terminated/failed.

According to this integration test code, a terminated orchestration results in runtimeStatus.IsCompleted() being true.

The second code block you're referencing is specifically for handling cascading terminate. It's not directly related to how we represent a currently terminated orchestration.

Actually, hang on - I need to double check. The code I pointed to is for orchestration metadata, not the orchestration runtime state object...

Okay, so confirming this wasn't as straightforward as I thought. But the short answer is that a terminated orchestration should always be completed. When an orchestration processes an ExecutionTerminated event, the SDK will generate a completedEvent with a status of "Terminated". This can be seen in the SDK code here.

Got it. Updated!

For consistency, we should follow the logging format that's used elsewhere in this file. For example:

This comment should probably be updated.

The PR LGTM, I just wanted to understand how are we skipping the creation of a new orchestration here, (i.e. the option SkipIfExists from microsoft/durabletask-go#42 (comment))

case api.REUSE_ID_ACTION_IGNORE:
		// Log an warning message and ignore creating new instance
		wfLogger.Warnf("Workflow actor '%s': ignoring request to recreate the current workflow instance", actorID)
		return nil

So if users choose REUSE_ID_ACTION_IGNORE and if there is an existing instance with the same instance ID, then we will enter the above block and just log a message and directly return.

my bad, I missed that Ignore is Skip, thanks for clarification