callActivity starts each process incorrectly with the same record iso each record from a collection

We have a process which we are porting from Activiti to flowable 6.5.0. The process manages a set of so called delivery points and is implemented with multiple flows. The bundledrop.master flow is the outer most flow. It will call the flow bundledrop.dropEan for each managed deliverypoint. This works fine in activiti.

We ported the bundledrop.dropEan flow first and everything is working as expected (proved by scenario tests that run entire scenarios through the flow).

While porting bundledrop.master flow the first test we execute fails. It is a happy flow test with three different delivery points. After analyzing the cause we found that callActivity calls the bundledrop.dropEan flow indeed 3 times, but each time with the same value for the variable deliverypoint. We have 3 different values (EAN1, EAN2 and EAN3), but the drop flow always get called with EAN3.

I added debugging output to the call that retrieves list (dropBundle.getDropBundleDeliveryPoints()) and it shows the 3 different values are there.

I added a bogus parameter with the value of loopcounter from the fragment below, and it shows it is always 2 for each call (I would expect 0,1,2). So we think something is wrong with the xml fragment we use:

The fragment in the xml is as follows:

<callActivity id="startNeededMarketProcesses" 
              name="Start Needed Market Processes" 

Does anybody have an idea what we are doing wrong ?

We found how we could get the code working. We have to set the flowable:async flag to false.

We did set that to true, because there is a task before this in the flow that only should be completed before the call activity is called. (it initialises some things in the database we wanted to have committed before the subprocesses start).

But I wonder if this is intentionally, I could not find anything about that in the documentation.

No, there’s nothing intentionally here: a call activity can be async (like any other type), if you want it to be async.

From the description (but hard to say without more details), I would expect it to work the other way around: setting it to async:true should have made sure the data is correctly there for the process to use.

That doesn’t sound correct. I’ll investigate if there’s potentially a bug there (loopCounter + async: true).