Famous One Task Process - Can't close task

In our application, we’ve been noticing the following error on some server environments but not others (ones that happen to have less memory).

org.flowable.common.engine.api.FlowableException: UserTask should not be signalled before complete

I could reproduce it using the “Famous One Task Process” by essentially opening up flowable-task, starting the process, and clicking Complete on the generated task. On any other servers, this completes just fine. Basically, this happens when completing any UserTask on these particular servers where others behave just fine. We’re installing these the same way each time and hosting in Tomcat.

Any idea what could trigger this behavior?

Probably need a lot more of the exception to get some clues.

Cheers
Paul.

Here’s the first half of the stack trace:

2019-08-21 10:47:13.826 ERROR 5091 — [io-8888-exec-43] o.f.u.t.s.r.FlowableTaskActionService : Error completing task AC78BF40-C421-11E9-88B9-0A02A07B244C

org.flowable.common.engine.api.FlowableException: UserTask should not be signalled before complete
at org.flowable.engine.impl.bpmn.behavior.UserTaskActivityBehavior.trigger(UserTaskActivityBehavior.java:246) ~[flowable-engine-6.3.1.jar:6.3.1]
at org.flowable.engine.impl.agenda.TriggerExecutionOperation.run(TriggerExecutionOperation.java:64) ~[flowable-engine-6.3.1.jar:6.3.1]
at org.flowable.engine.impl.interceptor.CommandInvoker.executeOperation(CommandInvoker.java:88) ~[flowable-engine-6.3.1.jar:6.3.1]
at org.flowable.engine.impl.interceptor.CommandInvoker.executeOperations(CommandInvoker.java:72) ~[flowable-engine-6.3.1.jar:6.3.1]
at org.flowable.engine.impl.interceptor.CommandInvoker.execute(CommandInvoker.java:56) ~[flowable-engine-6.3.1.jar:6.3.1]
at org.flowable.engine.impl.interceptor.BpmnOverrideContextInterceptor.execute(BpmnOverrideContextInterceptor.java:25) ~[flowable-engine-6.3.1.jar:6.3.1]
at org.flowable.common.engine.impl.interceptor.TransactionContextInterceptor.execute(TransactionContextInterceptor.java:53) ~[flowable-engine-common-6.3.1.jar:6.3.1]
at org.flowable.common.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:71) ~[flowable-engine-common-6.3.1.jar:6.3.1]
at org.flowable.idm.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTransactionInterceptor.java:49) ~[flowable-idm-spring-6.3.1.jar:6.3.1]
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:140) ~[spring-tx-5.0.6.RELEASE.jar:5.0.6.RELEASE]
at org.flowable.idm.spring.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:46) ~[flowable-idm-spring-6.3.1.jar:6.3.1]
at org.flowable.common.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:30) ~[flowable-engine-common-6.3.1.jar:6.3.1]
at org.flowable.common.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:56) ~[flowable-engine-common-6.3.1.jar:6.3.1]
at org.flowable.common.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:51) ~[flowable-engine-common-6.3.1.jar:6.3.1]
at org.flowable.engine.impl.TaskServiceImpl.complete(TaskServiceImpl.java:208) ~[flowable-engine-6.3.1.jar:6.3.1]
at org.flowable.ui.task.service.runtime.FlowableTaskActionService.completeTask(FlowableTaskActionService.java:65) [flowable-ui-task-logic-6.3.1.jar:6.3.1]
at org.flowable.ui.task.service.runtime.FlowableTaskActionService$$FastClassBySpringCGLIB$$e0796198.invoke() [flowable-ui-task-logic-6.3.1.jar:6.3.1]
at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204) [spring-core-5.0.6.RELEASE.jar:5.0.6.RELEASE]
at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:746) [spring-aop-5.0.6.RELEASE.jar:5.0.6.RELEASE]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163) [spring-aop-5.0.6.RELEASE.jar:5.0.6.RELEASE]
at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:294) [spring-tx-5.0.6.RELEASE.jar:5.0.6.RELEASE]
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:98) [spring-tx-5.0.6.RELEASE.jar:5.0.6.RELEASE]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:185) [spring-aop-5.0.6.RELEASE.jar:5.0.6.RELEASE]
at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:688) [spring-aop-5.0.6.RELEASE.jar:5.0.6.RELEASE]
at org.flowable.ui.task.service.runtime.FlowableTaskActionService$$EnhancerBySpringCGLIB$$1bf6aa78.completeTask() [flowable-ui-task-logic-6.3.1.jar:6.3.1]
at org.flowable.ui.task.rest.runtime.TaskActionResource.completeTask(TaskActionResource.java:38) [flowable-ui-task-rest-6.3.1.jar:6.3.1]

Usually when I hear “all the machines are all installed the same” my first reaction is some network issue (firewall, routing, co-location vs distributed, etc.) But I think here the clue might be “low memory”.

This is the line of code throwing the exception.

It would appear that task isn’t marked as deleted in the database yet which may occur because the database transaction hasn’t completed because of resource constraints (memory). Just a guess on my part.

FWIW, that particular area of code has received a far amount of attention since 6.3.1.

Good luck,
David

Thanks for the insight. I too was wondering if somehow this wasn’t deleting because I was looking at the same line of code.

It’s probably worth mentioning when I’m saying lower memory, I’m talking about 1gb allocated (which doesn’t seem that low). It’s the only difference I’ve been able to tell. Also, when I’m completing the task in flowable-task, it consistently throws this. So it’s not like it’s immediately after the process instantiation.

Actually, we may have introduced this as we noticed that these instances are using an unsupported database that we’ve made some updates for. Sorry for the noise!

Just to close the loop, we realized our db was set up for DISTINCT optimization which means a Select Distinct would return upper case collation for any IDs that were indexed (which is most IDs). A proper Task ID was coming in on the url, but one of the distinct calls was returning a upper cased version of the Task ID which down stream causes the issue.

Thanks for posting back the cause of the problem. This was the first time I heard about such a configuration :-).