Elsa 2.1.1.463, Multiple Published versions for the same workflow definition

Sometimes the IsPublished flag is set to true for more than one version of the same workflow definition.

I am using MsSql Server.

When ever that happens, I run the workflow and I get the following error.

{
	"errorMessage": "The call is ambiguous and matches multiple workflows.",
	"workflows": [
		{
			"WorkflowInstanceId": "0cbced1173fa49fb9768d1c7bb093d96",
			"ActivityId": "fe24e264-bcd5-4ca9-b3b1-a1166b3446ea"
		},
		{
			"WorkflowInstanceId": "0611ccc4bb854379a30af28f046d477f",
			"ActivityId": "fe24e264-bcd5-4ca9-b3b1-a1166b3446ea"
		}
	]
}

I am not able to reproduce this every time. It happens only some times.

The steps to reproduce are as follows.

1. Create a single Http Endpoint activity workflow as follows.

1. At this point, the db should show a single version which is not published yet.

1. Now click publish. This will make IsPublished to 1.
2. Next Edit the Http Activity. You dont have to change any configuration now, just click the save button. Now in the db, there should be two records.

1. Now the problem. Click publish, run the above query again and observe.

1. Note the ORDER BY Id and observe Version there. If the version appears in descending order as shown(2 then 1), I see that the bug is reproduced. That is the IsPublished flag will be set to 1 for both the versions. Now I delete the workflow def and start again and if this time, the version appears to be 1 and then 2, then things work correctly. That is, IsPublished is 1 for the latest only. And when I run the workflow, there is no error.

1. So I repeated this many times, Create, publish, edit-save and then publish. I consistently observed that if the version is 2 and then 1 the problem is reproduced, other wise not. So around 50% of times. Hope you will be able to reproduce this at your end. You can use the same Elsa.Bug.MultiTenency solution that I referred to in this bug earlier. If used make sure to comment out the following //.AddCustomTenantAccessor<CustomTenantAccessor>() in the startup class.

[Andrei-NZ]

Ok, I nailed it, but not sure how to fix properly - I am a couple of days into Elsa and workflows in general 😃

The intermittent issue is due to the WorkflowPublisher.cs and is a result of commit 197db287023031b7d26b2cfc27ccb1efb3ca6860.

On MS SQL

var publishedDefinition = await _workflowDefinitionStore.FindByDefinitionIdAsync(
                workflowDefinition.DefinitionId,
                VersionOptions.LatestOrPublished,
                cancellationToken);

generates correct condition

exec sp_executesql N'SELECT TOP(1) [w].[Id], [w].[Data], [w].[DefinitionId], [w].[DeleteCompletedInstances], [w].[Description], [w].[DisplayName], [w].[IsLatest], [w].[IsPublished], [w].[IsSingleton], [w].[Name], [w].[PersistenceBehavior], [w].[Tag], [w].[TenantId], [w].[Version]
FROM [Elsa].[WorkflowDefinitions] AS [w]
WHERE ([w].[DefinitionId] = @__Id_0) AND (([w].[IsPublished] = CAST(1 AS bit)) OR ([w].[IsLatest] = CAST(1 AS bit)))',N'@__Id_0 nvarchar(450)',@__Id_0=N'80bcb3e983f74929bbe8f82f8f91c145'

However if we have unpublished (and saved) version of a workflow, which is any workflow which has been altered, but not published i.e.

id	definition id	published	latest
1ae2c2eaa93347e4974af729393e900c	80bcb3e983f74929bbe8f82f8f91c145	1	0
006c21b56b1e40f785aae0180ff31985	80bcb3e983f74929bbe8f82f8f91c145	0	1

In this scenario, two records will match the OR condition.

Without ORDER BY, MS SQL will return records in random order, see here

In the example above, the order used seems to be ascending PK, resulting in the latest record to be on top, because the unpublished GUID starts with ‘0’ which is less than ‘1’.

As result the reset is executed on the latest workflow and not the last published.

  if (publishedDefinition != null)
            {
                publishedDefinition.IsPublished = false;
                publishedDefinition.IsLatest = false;
                await _workflowDefinitionStore.SaveAsync(publishedDefinition, cancellationToken);
            }

So we have a regression bug. We’d need to rollback #1261 and fix the issue addressed by #1261 differently. Should probably also add a safeguard where if retrieving a single entity yields multiple entities, a Warning is logged in the console, or something…

SQl trace to prove the above:

exec sp_executesql N'SELECT TOP(1) [w].[Id], [w].[Data], [w].[DefinitionId], [w].[DeleteCompletedInstances], [w].[Description], [w].[DisplayName], [w].[IsLatest], [w].[IsPublished], [w].[IsSingleton], [w].[Name], [w].[PersistenceBehavior], [w].[Tag], [w].[TenantId], [w].[Version]
FROM [Elsa].[WorkflowDefinitions] AS [w]
WHERE ([w].[DefinitionId] = @__Id_0) AND (([w].[IsPublished] = CAST(1 AS bit)) OR ([w].[IsLatest] = CAST(1 AS bit)))',N'@__Id_0 nvarchar(450)',@__Id_0=N'80bcb3e983f74929bbe8f82f8f91c145'

exec sp_executesql N'SELECT TOP(1) [w].[Id], [w].[Data], [w].[DefinitionId], [w].[DeleteCompletedInstances], [w].[Description], [w].[DisplayName], [w].[IsLatest], [w].[IsPublished], [w].[IsSingleton], [w].[Name], [w].[PersistenceBehavior], [w].[Tag], [w].[TenantId], [w].[Version]
FROM [Elsa].[WorkflowDefinitions] AS [w]
WHERE [w].[Id] = @__p_0',N'@__p_0 nvarchar(450)',@__p_0=N'006c21b56b1e40f785aae0180ff31985'

exec sp_executesql N'SET NOCOUNT ON;
UPDATE [Elsa].[WorkflowDefinitions] SET [IsLatest] = @p0
WHERE [Id] = @p1;
SELECT @@ROWCOUNT;

',N'@p1 nvarchar(450),@p0 bit',@p1=N'006c21b56b1e40f785aae0180ff31985',@p0=0

[sfmskywalker]

As chance would have it, I was running into this very same issue this morning myself. Your findings are spot-on. The best way to fix it is by retrieving ALL published AND latest versions of a workflow (in theory there should only ever be one, but sets affected by this bug would then auto-heal). That will also mitigate the bug that was fixed with 197db287023031b7d26b2cfc27ccb1efb3ca6860.

I will push a fix shortly.

Thanks for the detailed findings, this explained a lot, if not everything!