AndTask after loop never succeeds

I have a patch to fix this.
It is an issue with setting the regeneration flag on to many maestro_queue entities. In this case "Start"

I'd like to provide an automated test for this scenario.

Thank you for acknowledging that the workflow should have no issues.

This is a minimal workflow to demonstrate the issue.
I've tried to remove all unnecessary tasks. "dummy task1" is only there to make the pointers / arrows visible.
There can be more tasks anywhere and the problem persists.
The purpose of the AndTask is to wait for two parallel branches to finish.

The "AndTask wait" is not pointing back to start.

I've attached the template config and a patch to make the workflow run without issues.

There are some entity queries which can be optimized too. Should that be handled in this ore in a separate issue?

Your fix works as well. But i think it is confusing, especially with the comment above: "Race condition? ... Leave for now."

I did some git archaeology. The code appeared first in 2017. It looked like this:

          $query = \Drupal::service('entity.query')
            ->get('maestro_queue')
            ->condition('archived', '1')  //race condition?  what if its complete and not archived, yet a loopback happens?  Leave for now
            ->condition('status', '0')
            ->condition('process_id', $processID)
            ->condition('task_class_name', 'MaestroAnd');  //task is an AND
          $andIDs = $query->execute();  //going to use these IDs to determine who points to them

status == active and archived == archived is a condition which never matches. I interpret the comment as "This isn't working, somehow. So make it make it do nothing.
The code below was dead, effectively.

I have an idea what the problem was.

You observed the following:

In testing this patch, I see a new issue happening where for some reason the IF task does not work properly -- it does not follow the TRUE path and as a result, the dummyTaskToFix... task is always generated on first pass through.

That is an effect of reusing the $taskID variable in the loop over $pointers. $taskID is used to generate the task:

  $queueID = $this->createProductionTask($taskID, $template, $processID);

This is fixed with your latest commit.

I propose to remove the archive condition and the comment above.

I've created a merge request with my proposal and 2 test cases.

There is still an issue with the current logic. Because there needs to be a task between the IfTask and the AndTask. This is a limitation of the current data model. I think transitions between the tasks need to be recorded as well to resolve that problem. But that is for another issue.

The merge request has 2 templates. One with and one without a workaround task.

The tests are working but there is definitively room for improvement.

Please review.

I've updated the tests.

Fixed a bug in commit #3552704-2: Update AND task for false branch detection

NR for [3552133-17]

Workaround test removed.