Fixes for deduple behavior on orchestration create #123
Conversation
| @@ -504,14 +505,19 @@ public override async Task CreateTaskOrchestrationAsync(TaskMessage creationMess | |||
| command.Parameters.Add("@InputText", SqlDbType.VarChar).Value = startEvent.Input; | |||
| command.Parameters.Add("@StartTime", SqlDbType.DateTime2).Value = startEvent.ScheduledStartTime; | |||
|
|
|||
| if (dedupeStatuses?.Length > 0) | |||
| { | |||
| command.Parameters.Add("@DedupeStatuses", SqlDbType.VarChar).Value = string.Join(",", dedupeStatuses); | |||
There was a problem hiding this comment.
What will happen if "Running" is not among the dedupeStatuses passed in? Will this clobber a running orchestration?
There was a problem hiding this comment.
OK. Will not be a problem with our use, as "Running" is always included. I'm not sure what the Azure Storage backend would do?
There was a problem hiding this comment.
I just tested the behaviour of the Azure Storage backend. It seems that it will NOT clobber a running instance, even when "Running" is not among the dedupeStatuses. I don't get an exception (but then again, I never do with the Azure Storage backend) but the running orchestration will finish normally and not be restarted. Not so with "Pending" - a Pending orchestration will be replaced with a new one, if Pending is not among the dedupeStatuses.
Fixes #120
Note that this change may be breaking, depending on how exception handling logic is written. I suspect in most, if not all cases, the change from
InvalidOperationExceptiontoOrchestrationAlreadyExistsExceptionshould be non-breaking, hence, I'm releasing this fix as part of a minor version update instead of a major version update.