Race condition in signal processing

AlexFTrapp

Hi,
we have a process that starts a dynamic amount of parallel ack-user-tasks (to validate what was done in the previous step). The ack-Task allowes another user approve or decline. If one of the user "declines", we want to reset the process to the previous step. Having this scenario, we need to cancel the parallel ack-tasks that are still open because they are no longer needed.
We do that by sending a "done-signal" for the ack-tasks (caught by boundary-event). This normally works fine.
But sometimes the user dialog that "declines" is not yet finished before the "done-signal" is processed and so the dialog will stay open because the user-task is already marked as "done". We get an error message that the status of the task is not the way it should be.

I add the process-definition as a screenshot (see below):

is the user task for the acknowledge
sends a signal to check the "answer" of the user (which is received in the righthand part)
if declined: the processpart on the right is sending the "done-signal" for all parallel user-ask-tasks including the currently open task (done-Signal are identical)

Right now the race-conditions did only appear on the local mashine when implementing with the designer (currently 10.0.34), but we are not sure whether this will be a problem in productive environment.

Our question is:
Would that be the correct way to implement that kind of process? As we do have a 2-way-async signal-process we assumed that there would not be any race-conditions.
Any hints on how to define this kind of process (dynamic amount of parallel tasks that are to be canceled from another part of the process) are welcome.
Greets Alex

Lukas Giger

Hi AlexFTrapp ,

Not entirely sure why that race condition occurs off the top of my head. It might just be that, sometimes, the background action that properly finishes the task actually takes longer than the processing and handling of the signals.

Anyway, I think there's a much simpler design approach to this if that still fits your use case: Instead of creating multiple tasks for each user, have a role that each user is part of. Then, simply assign a single task to that role. All users of that role will then be able to work on that task and you can continue the process based on the decision. This avoids creating multiple tasks and having to handle (cancel) them individually.
I think this also avoids other caveats and edge cases you might run into. For example:

What if multiple users have the task open when one of them finishes it?
What if multiple users approve and/or decline at the same time?

Let me know if that helps.

Kind regards,
Lukas

AlexFTrapp

Hi Lukas,
thanks for your answer. What you proposed does not quite fit our use case. In our use case it is necessary that we get the approval of ALL persons (not only one).
We need for example 4 approvals and only if all 4 approvals are there, the next step in process will be allowed/started. If one of the 4 declines, then the previous step must be opened again and more work has to be done there to start the next "approval-run".
As the list of needed approvals is a dynamic list (depending of the content of the audited subject) we cannot create a static process with a fix order of approvals.
We call the check-step in every of those parallel tasks after the approval-trace-object was saved in the database, so If multiple users approve "at the same time", the last check will see that all approvals are "done" and send a signal to move forward to the next process step.
We made the assumption that even if the users press the button at the same time, there will still be one of the processes that is computed last and therefor will have the information about all previous approvals.
For declining it would be the same.

I was just wondering what would be the intended (Axon Ivy) way for the use case when:
i have a set of parallel tasks with a boundary event for killing and i would like to kill all the open tasks of this set according to an event that occurred during one of those tasks.

Thanks Alex

Lukas Giger

Hi AlexFTrapp ,

Alright, I see. That makes it clearer and definitely does not work with my previous suggestion.

I think your general idea is good. We actually have a process in one of our demo projects that implements a very similar pattern (maybe you've already seen it). See the ProcurementRequestDynamic process in the workflow demo project.
I think the crucial difference to your process is the system task element before sending the cancel signal. I would assume this fixes the race condition as it will create a new task and therefore properly finish the prior task before sending the signal.
{ProcurementRequestDynamic}

Let me know if you have any further questions.

Kind regards,
Lukas

AlexFTrapp

Lukas Giger

thanks for the hint. I will have a look at the example and will try to add that to our process.
As I understand from a first glance, this might really do the trick I was looking for.
In case I will fail, I will reply again.

Thanks again for the quick help,
Greets Alex