Multiple rows processed by Action are executed in parallel?

I am creating a Report process that once a month generates friendly challenges between teams. The 2 or more teams are created based on the # of enrolled members in a program. Members are then randomly assigned to the teams using a set of Actions that process iteratively (@Steve 's miracle looping actions) stopping when the correct number of members have been assigned.

Occasionally, when I run the process, I will get a member assigned to two different teams. I am fairly certain that this is due to the processing of the Team rows happening in parallel. As I watch the rows being written to the sheet they are not in a sequential team order implying multiple processes writing rows.

Additionally, I use the same construct (see example action below) to generate the Teams themselves and I can tell these are written sequentially. So, I suspect that once the number of rows to process reaches a certain number, parallel processing kicks in.

Does anyone have any experience to confirm the above?

If this is all true, there is a HUGE assumption being made here - that each row has no dependency on the other rows being processed. In my case, I am trying to take a pool of Program members and randomly assign them 2 or more teams. If those team assignments are for the same Program and being processed in parallel, then there is a risk that both pick the same random member at the same time ending up with a member assigned to two different teams within the Program.

As I think about how to permanently mitigate this issue, I am not seeing a way around it. No matter how I re-structure the processing, if parallel processing is truly being automatically introduced based on number of rows, then there is always a chance of the number of rows becoming large enough to encounter this issue.

I need some other way to randomly assign members to teams.

Any other ideas?


Example Action that Selects rows to be processed

1 2 235
2 REPLIES 2

UPDATE: Almost every test I performed resulted in a member being assigned to multiple teams.

I did figure out a way to avoid this for my use case. When I create a new Team, I then call the set of actions to assign member for just that single Team. This forces a sequential processing and ensures a member can be recognized as assigned to a team before the next Team is processed.

CAUTION: If you implement actions that process many rows at a time, pay very close attention that each row being processed is NOT dependent on other processed rows. This could be directly OR indirectly. Errors caused by parallel processing can be very difficult to track down.

Understatement

Top Labels in this Space