How to debug a condition on a backend workflow?

[ken1]

I have a backend workflow that runs in a loop.

1. I pass in a list.
2. Make changes in the database to the last item on the list.
3. I schedule the backend workflow again (for current time/date) and pass it the list minus the last item.
4. This continues until the last item has processed and none are left.

The problem is that the first call to the backend workflow is successful, but when it tries to schedule it again, the condition fails and none of the rest of the list get processed.

Here are screenshots of my setup, starting with the call from the frontend workflow:

Any ideas why the condition is failing when I try to call it again?

Thanks!

[mitchbaylis]

you need to either put a condition on the repeat api workflow or nest it in a custom event to force the order

currently the api workflow would just run as soon as the workflow is started

I’d also pass in the full list, then do a bulk delete of 50-100 each time and then custom workflow to reschedule if the list still has items - this will reduce the repeats and WU cost.

[ken1]

How do I do a bulk delete? The entire purpose of this backend workflow is because I thought I had to do this one-by-one.

To clarify, I don’t actually delete the database records. I need to record the delete date/time in each item. Can I do that in bulk somehow?

[mitchbaylis]

change list of things

delete list of things

[ken1]

It’s so strange. I’m getting the same problem as with the backend workflow. It only saves one, but not the others. If I delete that one, it doesn’t save the date/time to any of the records in my list.

So it must be something about those records, but I don’t know why. They are all the same data type! It makes no sense to me why I can’t save the dates here.

Any ideas on other things I should look for? I’ve checked permissions and that’s not it. I’m writing to these data types all the time all over my app.

When I inspect the list at the breakpoint, it has the correct records in it, so it’s not an empty list either.

[codydana415]

Hi Ken,

I agree with Mitch. Doing a bulk delete (“Delete a list of things”) is far more efficient than scheduling a loop to delete items one by one - especially if you’re dealing with large lists. Bubble can handle the bulk operation behind the scenes much more quickly than running a separate workflow for each individual item.

I saw your response on your unique scenario where you mentioned you need to “record the delete date/time in each item” and if you can do that in bulk. You can record a “deleted date/time” in bulk as well. The easiest way (Which Mitch had mentioned) is:

Make changes to a list → set deleted_date = Current date/time for the entire list.
Delete a list of things → the same list.

Now if you continue to have issues that you mentioned using the bulk method - “I’m getting the same problem as with the backend workflow. It only saves one, but not the others. If I delete that one, it doesn’t save the date/time to any of the records in my list.”. Here are some debugging steps …

1. Double check everything and recheck your privacy rules (turn everything off)
2. Confirm your referenced list is truly a list. If your expression in “List to change” is referencing something like Search for [Thing]:first item by accident, you’ll only ever get one record. (:first item). Make sure it’s Search for [Thing]

I saw your comment “When I inspect the list at the breakpoint, it has the correct records in it, so it’s not an empty list either.”…

At this point, i suggest creating a simplified version of what you’re trying to do without any constraints (Only Whens) and a new data type (just to get past the suspicion “So it must be something about those records, but I don’t know why.”)… If this simplified version updates all items as expected, then something in your original setup conditions, privacy, or a different expression - must be limiting the list in that specific workflow. At that point you’d work backwards on your main development until you pinpoint the cause.

Please let me know what you find

[ken1]

Thanks for the advice everyone! I did end up changing from the backend workflow to the bulk delete. I think I originally created the backend workflow so that I could delete everything immediately from my frontend without making the user wait for the database to update to see the changes. But I realized based on my setup I can still do this on the frontend now (I didn’t have the same workflows when I first set it up).

But to the question of the troubleshooting my error. I still think it’s unnecessarily difficult to troubleshoot a backend workflow. In any case, I was getting the same problems from my frontend bulk delete.

It turns out this was a timing error. I needed to slightly change the order of my steps and force that they would execute in the correct order. I did this using the wonderful Listful plugin and the Keeper elements where you can control the order of execution of steps.

Thanks again for all the help.