API Workflows (Both Recursive and on List): Asynchronous reliability

Hi all,

I have intentions to create a looping workflow as follows:

API Workflow A:

  1. GET paginated List of data from external service (100 items)
  2. Trigger API Workflow B, send List to API Workflow B
  3. Trigger API Workflow A for next page of 100 items

API Workflow B: This can either be a Workflow on a List or a Recursive Workflow

If Workflow on a List:

  1. Create a Thing from each individual item in List from API Workflow A

If Recursive Workflow:

  1. Create Thing from first item on List
  2. Minus the first item from List
  3. Trigger API Workflow B, repeat till 100 items are done

My question is how reliable is asynchronous workflows like the above in Bubble? Would you choose to do it with a Workflow on a List or a Recursive Workflow?

My concern with the Recursive Workflow approach is that I’m unsure if the continued runs of API Workflow A, where it continues to send to API Workflow B Lists of 100 items, would mess up the recursive flow of API Workflow B.

Thanks for insights!

@felix1 Did you ever find a solution for this? I’m looking to do the exact same thing but havent been able to get it working. Any insight would be greatly appreciated!

If Workflow on a List:

  1. Create a Thing from each individual item in List from API Workflow A

I went with this option in the end, but we’ve not launched yet, so this is yet to be tested in the wild.

Thanks for the response. Please keep me posted.

I’m going to try to conditionally run step 2 if {offset_value} exist in the response from step 1, dynamically passing offset value into the GET request of step 2.

If {offset_value} is null, end workflow.

Once I test this, I’m happy to report back with any (seemingly) useful info.

Cheers!

Hi @felix1 @SolMi , I’m having an issue in a similar recursive workflow where the thing operated on in step 1 is not being removed from the list of things when using :minus item to create the updated list of things for the workflow.

Any experience dealing with this?

I’ve been using recursive workflows for years and it has been very reliable. I’ve once shared my initial thoughts here: Schedule API workflow on a list - does the list have a limit? - #23 by rico.trevisan

@mihira can you show your workflow? I will try to help. Maybe relevant, the next post in the above thread, deals with the :minus item quirk that it can remove more than one item.

Hi @rico.trevisan , Thanks for that. It’s pretty much the same as what you’ve done except the list is comprised of database things instead of texts. See below:

The recursive workflow is dependant on the “ItemSegList” and “ItemSeg” fields, where “ItemSeg” is the individual database thing that is being modified.
Problem is that the list never actually reaches count=0 so it goes on forever.

Thanks for taking a look!

2 hunches:

  1. Could simplify the variables?
  2. What happens if you use the same formula that you’re using on Step 2 (instead of : minus Result of step 2)

On simplifying

  • It looks to me that you can remove ItemSeg completely. Because that is already present in the ItemSegList. Am I correct?
  • Is Items the list that contains that item? If yes, could you not remove that item?
  • Can Items be deduced or searched for based on the ItemSegList? If yes, could you not remove Items?
  • … same as above but for Segment?

Thanks @rico.trevisan , I did like below and it works for now:


These expressions seem to be unreliable, because I have other recursive workflows setup which use :minus result of a previous step (to make sure that the previous step runs first) and those workflows work fine.

I feel like I need to now go back and change those to this format.

FYI, Items and Segment are just data that is needed for steps 1,2 and subsequent workflows.

1 Like