Is there any way to terminate workflow in an API Endpoint if an action fails?
e.g. A workflow acton (Stripe charge attempt) where no response comes back at all.
After attempting a charge… things are created and modified in Bubble, but I don’t want to create/modify those things if a workflow action fails.
Unfortunately, I don’t think there’s an official Bubble solution to this problem as yet…
Hi @Ebz
Use the action Terminate (with the error condition) in front of the rest. Welcome to Bubble! 
Hi @JohnMark,
I have a Terminate in front if an error response comes back, but what happens if nothing at all comes back?
Also, is the only option to create terminates for every possible error condition in lieu of saying ‘is empty’? I could see it continuing past a ‘is empty’ condition if no error response comes back at all.
Yes my reply will be ‘if empty’. Doesn’t work? but hold on… create a variable and check that variable with the error variable (with a concatenate),
if it is the same value, you know it is empty .
Maybe it will work? @sudsy Steve 
Ok, I am working on this now so I can test to see if this is a good solution.
Thanks @JohnMark!
Hey, it’s worth a…@shot…I guess! (Booo!) 
Sure wish I knew where API error (or just http response code) handling is on the Bubble roadmap - assuming it’s there at all. This is especially important, it seems, for payment handling.
Hopefully, @Ebz will let us know if that suggestion works.
We need all HTML response status code options in the Return Response from Workflow action in the worst way. (Also that Backend Workflows be GETtable.) This would open up so many new capabilities.
(And I just don’t see how this particularly hard to add.)
Thank you for starting this @Ebz and for linking the additional threads @sudsy. I am having the exact same struggles with trying to set up fail safes with Stripe. Funny enough I was searching the forum for help yesterday, found this thread, and realized you started it only 2 hours prior.
I have approached my wits end with this. I have tried multiple setups using “terminate workflow” actions to “Only When” conditionals on the WF actions, and the best I can get is an unreliable process that works 50% of the time, which is maddening, and an unacceptable nonstarter to launch in public
My current setup starts like this. I built a cart, so the first WF action is to trigger a backend (API) workflow on a list of “orderlines”.
Below is the backend workflow on the list of orders. I am using the Zeroqode plugin in the first 2 actions to create the charge. This third action is based on whether the charge is captured using “only when” where it will write to the “orderline” row “yes” if it is processed by Stripe. This seems to be working reasonably well now. The issues occur after we come out of the API workflow and back into the regular workflow.
The second step after the API part, is to trigger an alert if the “processed by Stripe” field is empty, for any of the recently processed orders. Issue is, the fail message is triggered DESPITE the fact the order has been processed – both actually captured by Stripe, AND written as “yes” processed by Stripe in my DB.
Step 3 is supposed to terminate the remainder of the workflow if processed by Stripe is empty (the same conditional as step 2). This fires and kills the rest of the workflow too, so it clearly didn’t get the message either.
I have tested this dozens of times and it literally works the way it should every other time. Half the time it triggers the charge failed message when the charge did not fail, the other half it works. It’s crazy. Does anyone know why the step 2 in the regular workflow process seems not to be able to read the result of the backend workflow sequence?
Is the backend WF not occurring quick enough for the regular WF to recognize the result? I thought it was all sequential, but perhaps it is not after reading through some other issues people have had. Before this I tried having terminate workflow actions inside the actual backend WF, but that proved not to work so well and there were issues there too when attempting to read previous steps. And also questions on if you can use a “terminate workflow” inside a backend workflow will that only kill the backend workflow, or will it kill all the other workflows in the regular workflow too?
Maybe we can row out of this conundrum together.
Any insight would be appreciated, and hopefully my post helps add to the discussion.
Hi Mark, just a quick observation right off the bat…
A scheduled API workflow is, by its very nature, asynchronous; so the first step in your WF schedules something to happen at some point in the future and then immediately moves to step 2.
So your hunch was right. Things aren’t happening in the order you expect - probably because you’re expecting the scheduled workflow to complete before moving to step two. All that’s happening in step one is the scheduling of the workflow - not the actual steps comprising the workflow. So, sometimes those steps occur before step two, and sometimes not.
I’m sure others will have more to say, but that’s just a quick initial observation.
@sudsy, thanks for the response here.
That’s my sense now, after so much frustration thinking things were sequential.
I think the reason I thought that these processes were sequential is that you can specify when to schedule an API workflow, so if you are scheduling it to fire now (current date/time), then why would the order not maintain the sequence laid out? That makes no sense. Though I suppose that’s the purpose of calling it “backend workflows” now to better illustrate the asynchromonious nature as you put it, but there SHOULD be an option for sequential backend workflows to help process lists.
Extremely frustrating.
So if I am trying to process multiple orders in a cart, how then am I able to perform this and ensure things fire in sequence? Should I be adding a pause workflow action after the step 1 API Workflow, and guess the time it takes to complete? That doesn’t seem like a reassuring place to be when a marketplace product needs to be completely solid with processing for it to be worth anything.
Is there anyone at bubble we can rope into this conversation that could help?
Agree here, completely. “Backend” or asynchronous should detach the workflow from the UI and make it reusable, not mean that the individual actions within the workflow sometime fire out of sequence or don’t happen at all.
Slow it down? Sure. Timeouts? I see the need. But just having the workflow blunder along through each step regardless of whether it’s completed? I don’t get that part.
Think of it this way: If procedural code worked like this society would fall apart in minutes.
Hi there,
I’m wondering if you figured out how to get workflow steps that include calling a backend workflow, to execute sequentially every time.
Thanks.
@marktuff @sudsy @benedict @emmanuel
Did anyone have any ideas on how the above can be made sequential?
Hi @anthony.hull : I found this post very helpful, especially the image someone created further down the thread:
Hope it helps.
