ELSA 3.4 Join WaitAll behaviour

[JochenSteinbrenner]

Hello,
after update from 3.2 to 3.4 the join behaviour for wait all does not react as expected. Within 3.2 the WailAll continues, when all inbound activtivities has finished.
In 3.2 the WaitAll activity continues. When "Discharge: SmallIngs" & "Weighing: SiloIngs" has finished.
In 3.4, WaitAll stay in waiting...
For example:

Weighing:SiloIngs: Finish within a later resume...

Discharge:SmallIngs: Finish directly after workflow start..

Is there anything changed in 3.4? Did I miss something?

Thank you for your help!
Regards Jochen

Update: You have to create a fork with two branches which are finished asynchronously. In my example the first branch of the inbound waitAll finishes directly. The second branch suspends and finishes later in a resume.

2025-05-22 15:00:37.425 [AZO.KastorEngine.Server][1.0.0.0] [Fatal] [Workflow] BBB
2025-05-22 15:01:08.169 [AZO.KastorEngine.Server][1.0.0.0] [Fatal] [Workflow] AAA

[sfmskywalker]

@JochenSteinbrenner Indeed the join behavior has undergone significant changes, which fixed some scenarios, but from the looks of it, have introduced different issues. For me to investigate this in further detail, would it be possible for you to share some workflow files with only built-in activities, or if necessary, including custom activities containing only the bare minimum of logic necessary?

I will then try them out in 3.2, 3.4 and 3.6 - these versions each have a different implementation of the join behavior. I suspect that the 3.6 version will have no problems, but I would like to better understand what is going on with the behavior in 3.4.

[JochenSteinbrenner]

Hello Sipke,
refer to attached exported workflow. You can start in directly within the designer. It uses the build-in "writeline" activity and the "delay" activity from ELSA.Scheduling with the same result. The Join activity with "all" does not finish if an incoming branch is finished in a later resume of the workflow (if both incoming branches are finished in the same execution/trigger, join finishes nornmally. I think the join activity has problems when incoming branches are finished in different triggers...).

test-join.json

Thank you for your help!
Regards Jochen

[sfmskywalker]

Hi, not yet, but it's on my radar.

[JochenSteinbrenner]

Perfect, thank you!

[sfmskywalker]

I just tried the attached workflow with 3.4.1 (currently in preview), and I did not see the same issue - the workflow behaves as expected:

• The first branch continues until the Join activity.
• After 30 seconds, the second branch resumes and completes the Join activity, subsequently completing the entire workflow.

I created a recording: https://screen.studio/share/MjhuKnsU

Although I have to still try this on 3.4.0, maybe you can try with the 3.4.1 patch preview in the meantime and let me know what you find. If you are still seeing this issue, then please provide me wit ha simple project that I can run.
I suspect I won't be able to reproduce it with 3.4.0 either, given that 3.4.1 does not introduce any changes that relate to the flowchart and joining behavior (that I could see).

[JochenSteinbrenner]

Hello, thank you! I'll check version 3.4.1...
The difference I see is, that you trigger the workflow within the Designer. I'll trigger the workflows within my backend programatically. Maybe there is a problem in my implementation. I verify that and write a response as soon as possible.
Regards Jochen

[JochenSteinbrenner]

Current implementation to start or resume:

private async Task<WorkflowState> StartWorkflowAsnyc(WorkflowDefinition workflowDefinition
            , EcsEntity entity, Dictionary<string, object> input, CancellationToken cancellationToken)
        {
            if (workflowDefinition == null)
                throw new EcsArgumentNullException(nameof(workflowDefinition));
            if (entity == null)
                throw new EcsArgumentNullException(nameof(entity));
            var workflowClient = await workflowRuntime.CreateClientAsync(cancellationToken);
            var workflowGraph = await workflowDefinitionService.FindWorkflowGraphAsync(workflowDefinition.DefinitionId, VersionOptions.Published);

            var createRequest = new CreateWorkflowInstanceRequest
            {
                WorkflowDefinitionHandle = WorkflowDefinitionHandle.ByDefinitionVersionId(workflowGraph!.Workflow.Identity.Id),
                Input = input,
                CorrelationId = entity.WhoAmI
            };
            var createResponse = await workflowClient.CreateInstanceAsync(createRequest, cancellationToken);
            var runRequest = new RunWorkflowInstanceRequest()
            {
                Input = input
            };
            var runResponse = await workflowClient.RunInstanceAsync(runRequest, cancellationToken);
            var workflowState = await workflowClient.ExportStateAsync(cancellationToken);
            entity.WorkflowRef.StartedAt.Value = DateTime.Now;
            return workflowState;
        }

        private async Task<WorkflowState> ResumeWorkflowAsync(WorkflowInstance workflowInstance
            , string bookmarkId
            , Dictionary<string, object> input, CancellationToken cancellationToken)
        {

            if (workflowInstance == null)
                throw new EcsArgumentNullException(nameof(workflowInstance));
            if (string.IsNullOrEmpty(bookmarkId))
                throw new EcsArgumentNullException(nameof(bookmarkId));

            var workflowClient = await workflowRuntime.CreateClientAsync(workflowInstance.Id, cancellationToken);
            var request = new RunWorkflowInstanceRequest()
            {
                BookmarkId = bookmarkId,
                Input = input
            };
            var response = await workflowClient.RunInstanceAsync(request, cancellationToken);
            return await workflowClient.ExportStateAsync();
        }

[JochenSteinbrenner]

@sfmskywalker Hi, first of all, sorry for my delayed answer...

I've checked it with both 3.4 and 3.5 RC1 (3.4.1 is not available yet). Same behavior.
The delayed branch does not cause the Join to finish and continue.

WebApplication1.zip
I created a small example ELSA server based on the example ASP.NET web API project with the minimal setup, I have.

• MongoDb persistation
• Admin user
• JavaScript
• Scheduling

I am using ELSA studio as docker container to run the workflow:
test-join.json

Same behavior...
Refer to video:

Can you please investigate the problem? Did I missed something important?
Cannot upgrade from 3.2 to 3.4 at the moment...All other thing very good!

Regards
Jochen Steinbrenner

Elsa studio yaml:

 azo.kastorengine.server.elsa.studio:   
    image: elsaworkflows/elsa-studio-v3-4-0:sha-a2a7d33
    environment:
      ASPNETCORE_ENVIRONMENT: ${ASPNETCORE_ENVIRONMENT}
      HTTP_PORTS: "8080"
      ELSASERVER__URL: http://localhost:43311/elsa/api      

[sfmskywalker]

Hi @JochenSteinbrenner ,

No worries at all - thanks for the repro!
I was able to pinpoint the issue to something not right with the MongoDB provider. - it works fine when using EF Core (and upgrading to 3.5.0-preview.3112, I have not tested it with 3.4.0 yet).

I'll share more details here once I figured out what the issue is with the MongoDB provider.

[sfmskywalker]

The serialization issue with MongoDB has been fixed via #6762 and will be part of the upcoming 3.5.0 release.

Thank again for the wonderful repro, that really helped 👍🏻