We are moving from using Flowable 5.21 to using Flowable 5.23 and one test case fails in our testsuite after this change. The scenario is the following: a service task executes a bean’s business method. In this test it is configured to fail when being called for the first time and then succeed when it is retried. With 5.23 the retry never happens. Would you have any hints where to look? I noticed that there were some changes in Flowable in the meantime around the code for timers and async jobs, but I have not yet looked into it in depth.
I’m trying to investigate the problem. In the logs using 5.21 I see debug logs from a thread picking up async tasks, they are all over the logs.
In 5.23 tests I cannot see such logs. In fact, if I am grepping correctly, there are no logs from this thread, the one picking up async jobs. Is it possible that this thread is dead or not even started?
Is it possible that 5.23 needs a slightly different configuration? We are using Spring.
No there haven’t been any changes to the async or error handling logic to my knowledge. The changes to the timer and async jobs were done in Flowable 6 not in 5. Did you do some changes in your process engine configuration or does the code just work with Flowable 5.21 and not anymore with Flowable 5.23? Is it possible to create a unit test, so we can try to reproduce the issue?
51c4ad35 - maybe I’ve seen one or two more commits which have a description mentioning Async Executor.
Actually, you have a test for a retry scenario. But the test starts and stops these threads for the duration of a test. If I were to write another testcase I would take Spring boot with its default configuration of Flowable and run a retry scenario against such setup. This is basically what our testcase does.
In such scenario the code works with 5.21, now I’ve checked that it works with 5.22, it fails with 5.23. No changes made except for the Flowable version number. Well, we have some other component called Activiti-Schema-Generator - not sure what it does - where I need to change spring.activiti.checkProcessDefinitions property name to activiti.checkProcessDefinitions. But I think that is not related in any way.
It would be good to have a test case without Spring boot, because that adds an additional layer of complexity. It’s difficult to help you without a test case that shows the issue on the Flowable Engine.