Flowable task complete issue - UserTask should not be signalled before complete

Flowable Engine
1

Hi,

We are facing below issue details:-

Prerequisite:-
We are using flowable version 6.6.0 as a dependency in spring boot application.

Problem statement:-
We are getting a issue “UserTask should not be signalled before complete" while completing a specific stage.
We have a BPM flow refer below flow diagram just for reference.

bpm
bpm1535×475 9.18 KB

in which sometimes while completing a “E” stage which is after few parallel stages(“B”, “C”), we are facing an issue “UserTask should not be signalled before complete” in BPM logs

java.lang.Exception: UserTask should not be signalled before complete
       at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
       at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:771)
       at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
       at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:749)
       at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:366)
       at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:118)
       at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
       at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:749)
       at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:691)
       at sun.reflect.GeneratedMethodAccessor777.invoke(Unknown Source)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
       at java.lang.reflect.Method.invoke(Method.java:498)

Temporary Solution:-
We have analysed the issue and found a temporary solution that in “ACT_RU_TASK” table we get multiple records for that task.
SELECT * FROM ACT_RU_TASK art WHERE PROC_INST_ID_ =‘PROCESS_INSTANCE_ID’
We were able to complete the stage “E” after removing those multiple records and keeping a single record in “ACT_RU_TASK” table.

We are looking after the root cause of this problem and need a permanent solution.

2

That particular exception is thrown here: https://github.com/flowable/flowable-engine/blob/main/modules/flowable-engine/src/main/java/org/flowable/engine/impl/bpmn/behavior/UserTaskActivityBehavior.java#L322

and it happens when trying to complete a task, when it’s aready been completed during the same transaction. Are you deleting the process instances potentially beforehand or simultaneously?

Note sure what this means, can you clarify?

3

Hi,

We are not deleting the process instances potentially refer below code that we are using for completing task.

taskService.complete(TASK_ID,VARIABLES)

We found that there were two records in “ACT_RU_TASK” table when we got this issue.

So after deleting previous records we are able to complete task.

4

I have the same exception on 6.8.0.
Problem:
There are 3 tasks associated with one execution. Model:

(start) -> <X> -> (UserTaskA) -> <X> -> (end)
            ^                     |
            |--- (UserTaskB) <----

The UserTasks are asychronous.
There are 3 user tasks instances:
A (id-1)
B (id-2)
B (id-3)

I’ve checked historic activity instances. Id-1 and Id-2 are logged in historic activities for process instance, but Id-3 is missing. Id-3 is missing in all historic activities.

My guess:
Id-3 was created with wrong execution id. The thread has got the context of another execution, and that’s why id-3 was created in the “wrong” execution. It could happen when service beans are not thread safe:

I am only guessing…

Martin

5

hmm use exclusive jobs (flowable:exclusive="true") when marking tasks async to prevent concurrent operations on the same process instance and if u see multiple rows for the same task in ACT_RU_TASK, that’s a sign a second execution path or compensation path is recreating it by mistake

6

exclusive jobs (flowable:exclusive="true")

Has no effect in my case → there is always only one child execution for my process instance. (X) exclusive gateway does not create a new execution.
The problem is at the end 3 tasks were created for one execution, and execution itself is on the last activity - user task.

Regards
Martin

7

Hmm,I am not an expert but it’s likely still a concurrency or modeling hiccup, even if your gateway is exclusive, getting three tasks for one execution usually means some extra code path or threading is sneaking in and duplicating tasks, make sure all async tasks are really “exclusive” so they don’t get processed in parallel it’s easy to overlook something small that ends up spawning that extra user task