Error "Can only trigger a plan item that is in the ACTIVE state" on completing/abandoning a task since I updated from 6.5.0 to 7.0.0M1

Flowable Engine
1

Hello !
I’m a french developper, I work for a company which uses Flowable engine, and recently, the team decided to upgrade Flowable version from 6.5.0 to 7.0.0M1.

Now, we have a problem when executing End Event / End Terminate event :

Stack Trace from “complete” action, which is supposed to trigger my Process BPMN to End Event :
Exception occured : org.flowable.common.engine.api.FlowableIllegalStateException: Can only trigger a plan item that is in the ACTIVE state at org.flowable.cmmn.engine.impl.agenda.operation.TriggerPlanItemInstanceOperation.run(TriggerPlanItemInstanceOperation.java:47) at org.flowable.common.engine.impl.AbstractEngineConfiguration.lambda$new$0(AbstractEngineConfiguration.java:195) at org.flowable.cmmn.engine.impl.interceptor.CmmnCommandInvoker.executeOperation(CmmnCommandInvoker.java:86) at org.flowable.cmmn.engine.impl.interceptor.CmmnCommandInvoker.executeOperations(CmmnCommandInvoker.java:73) at org.flowable.cmmn.engine.impl.interceptor.CmmnCommandInvoker.execute(CmmnCommandInvoker.java:59) at org.flowable.common.engine.impl.interceptor.TransactionContextInterceptor.execute(TransactionContextInterceptor.java:53) at org.flowable.common.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:105) at org.flowable.common.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:30) at org.flowable.common.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:56) at org.flowable.common.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:51) at org.flowable.cmmn.engine.impl.runtime.CmmnRuntimeServiceImpl.triggerPlanItemInstance(CmmnRuntimeServiceImpl.java:130) at org.flowable.cmmn.engine.impl.callback.ChildProcessInstanceStateChangeCallback.stateChanged(ChildProcessInstanceStateChangeCallback.java:36) at org.flowable.engine.impl.util.ProcessInstanceHelper.callCaseInstanceStateChangeCallbacks(ProcessInstanceHelper.java:540) at org.flowable.engine.impl.persistence.entity.ExecutionEntityManagerImpl.deleteExecutionAndRelatedData(ExecutionEntityManagerImpl.java:578) at org.flowable.engine.impl.persistence.entity.ExecutionEntityManagerImpl.deleteExecutionAndRelatedData(ExecutionEntityManagerImpl.java:591) at org.flowable.engine.impl.persistence.entity.ExecutionEntityManagerImpl.deleteProcessInstanceExecutionEntity(ExecutionEntityManagerImpl.java:630) at org.flowable.engine.impl.agenda.EndExecutionOperation.handleProcessInstanceExecution(EndExecutionOperation.java:119) at org.flowable.engine.impl.agenda.EndExecutionOperation.handleRegularExecution(EndExecutionOperation.java:300) at org.flowable.engine.impl.agenda.EndExecutionOperation.run(EndExecutionOperation.java:82) at org.flowable.common.engine.impl.AbstractEngineConfiguration.lambda$new$0(AbstractEngineConfiguration.java:195) at org.flowable.engine.impl.interceptor.CommandInvoker.executeOperation(CommandInvoker.java:130) at org.flowable.engine.impl.interceptor.CommandInvoker.executeOperations(CommandInvoker.java:114) at org.flowable.engine.impl.interceptor.CommandInvoker.execute(CommandInvoker.java:72) at org.flowable.engine.impl.interceptor.BpmnOverrideContextInterceptor.execute(BpmnOverrideContextInterceptor.java:26) at org.flowable.common.engine.impl.interceptor.TransactionContextInterceptor.execute(TransactionContextInterceptor.java:53) at org.flowable.common.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:105) at org.flowable.common.spring.SpringTransactionInterceptor.lambda$execute$0(SpringTransactionInterceptor.java:57) at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:140) at org.flowable.common.spring.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:57) at org.flowable.common.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:30) at org.flowable.common.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:56) at org.flowable.common.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:51) at org.flowable.engine.impl.TaskServiceImpl.complete(TaskServiceImpl.java:223)
… (the rest of the stack trace is our application code)

In our database, the item is in “active” state, but also when we are debugging we have the right “Task” element with the right id.

Maybe the “complete” try to complete an other process in an other plan item ?

If you need more informations to help me solve this issue, you can ask me.

2

@olivierjiva this looks like a bug we have fixed on main. Is it perhaps possible to share a minimal example for how to reproduce this? e.g. a case and a process that you can share so that we can try it out (or maybe an example repo showcasing the problem)

3

@filiphr thanks a lot for your reply, I need some time to prepare this “minimal example” because there is actually a lot of code around this projet and it would be painfull to read … I will come back soon for this.
For the moment, do you think we should downgrade / upgrade our Flowable version to avoid this problem ?

4

If you can easily reproduce this problem I would suggest that you try to upgrade to a version that does not have that problem. If you do this, let us know which version that is. This way we might be able to pinpoint in which exact version this started to be a problem.

5

Hi @filiphr , I will find some time this week to reproduce this bug.
I didn’t explain all the problem around this version : we try to get Flowable 7 because it seems to be the only version compatible with Spring Boot 3 : Also, it seems that it is a “pre-release” version, so I just wanted to know if a release version will come soon ?

6

We are working on releasing another Milestone for Flowable 7. The difference between 7 and 6.8 is mostly in the Spring Boot 3 compatibility. In the core there aren’t any changes that should be different. That’s why I asked to try some of the other versions because it could mean that something broke in some particular version.

But if you manage to reproduce it with 7 M1 then it would still be helpful since we would be able to fix it easily.

7

Thanks again, I managed to reproduce the bug in 6.6.0 ! So it seems that the bug appears from 6.5.0 to 6.6.0.
If you have a clue to what it can be it can helps me a lot…

8

Hello, I’m reopening this topic to find out if you’ve encountered this problem / or if you’ve solved it since the release of version 7.0.0 ?