Reliability of scheduled API Workflows

I have a series of API Workflows that call other API Workflows in order to create a unique copy of a thing and all its sub-fields. (Since the default list copy function does not do this). Most of the time it runs great, but sometimes something goes wrong and the resulting copy is not perfect. What might be the cause of this, can we not count on server side workflows to run perfectly every time?

Do you see App too busy in your logs? That’s what I’ve seen in the past and means you need to upgrade to a larger plan.

Just went through my server logs, didn’t find any errors or any indication of app being too busy.

API workflows are asynchronous, it mean (you probably know) that if you run many workflows on same data, then eventually, you will observed that syndrome happening. You must find the way to not call the same data.

I want to make sure I understand what you’re saying. Basically the issue is that I have multiple calls on the same data, causing an error? and that I need to find a way to make sure it happens in sequence?

It’s not causing any error, it’s simply not able to wrote data, but continue the process. In sequence will be best, until you found the guilty one.

This seems like it may be a pretty tough issue to solve, any tips? Appreciate the feedback already, thanks!

1 Like

It may help us if you can post screenshots of your workflow.

These are the 3 API Workflows, essentially I’m recursively constructing a copy of a thing and all its sub things.

The object i’m reconstructing looks like this
—Workout Template
-----List Of Workout Groups
-------List of Set Groups
-----------List of set objects

I provide the First API call with the reference object to copy, then it copies the first sub list, before calling another API workflow for the next sub-list of things. This continues until it gets to the “bottom”. Hopefully that makes sense.

Make sure you enter a number like “10” or greater into the Interval fields that are showing in red. This will slow down the workflow. I still think you are experiencing Bubble terminating workflows if it uses more CPU than your plan allows.

You could also put a condition in the “Only When” field on your Step 3s to “Result of Step 1 is not empty”.

If you go to the Logs page. Does the “Duration where the app hit it maximum… last 24 hours” have anything other than 0?

Going to try implementing that, and no, it shows 0

using “only when” does not fix it, and using a 10 second interval is much to long. I recreate this object and then the user uses it. A small pause is fine, but that would take a very long time.

Do it in the page then. JavaScript. Toolbox… you’re just gonna have to learn them.

(Don’t worry, bubble is still the bomb when you do this. Sometimes you just have to do things the old fashioned way.)

Got it, So I can write these API actions via java script and implement them that way?

OR… it could be that you’re thinking about it the wrong way. Sounds like you’re just trying to build up a new complex object from component parts? Can’t you just take the handles to the sub objects you already have, copy those, copy the next level up, etc.? Until you have the completed Thing?

Throwing it to the server will never be faster than doing those operations in the page.

Possibly, will give it some thought, thanks! The main benefit for me server-side was that if a user loses connection, it wouldn’t result in am imperfect copy.