Because it might be interesting/relevant for someone else, I did some small scale testing assigning 4 Users a Word each in two slightly different recursive workflows. It is a very small test, but its a real pain following the logs in Bubble (then resetting the data to try another way), so this is what we are going with.
In the first, I used the screenshots above, where the last step of the workflow, which schedules the next ‘loop,’ uses “minus item” to remove reduce the size of the two lists (Users and Words).
Reducing List Size each Loop
Initial WF: 1.43 (Button press and Search)
Then WUs per iteration decrease as list decreases in size:
3.03 → 3.00 → 2.97 → 2.93 + 1.2 to end overall (action condition failed).
= 14.56 total WUs
In another test, I instead used an “index” method, where the list stays the same size, but I increment an index value on each ‘loop’ (this is the method AirDev recommends in their documentation/guides).
Incrementing an Index each Loop
Initial WF: 1.43 (Button press and Search)
Then WUs per iteration are lower, but do not decrease:
2.93 → 2.93 → 2.93 + 2.23 (action condition failed)
= 12.45 total WUs
Interesting the index method is fewer overall WUs for the same result and that reducing the list size each loop doesn’t decrease linearly.
The decreasing loop numbers are close enough though, so perhaps its a random server variation and .03 is the additional cost of each item on the list. If that is the case, then a list of 1,000 items would add around 30 WUs to whatever the first loop costs to process on its own.
I may try passing the unique IDs of the Things to the backend WF instead of the Things themselves and see if that reduces the WU usage.
For completeness, the backend workflow being triggered:
- Modifies 3 fields on the Word Thing
- Modifies 1 field on the User Thing
- Increments the index (index + 1)
- Conditionally schedules the next loop while index < count (count = # of items, given by the frontend button that calls the workflow)