Backend worflow calling itself -> infinite loop

Hello ! By mistake I defined a backend workflow that is calling itself. So I am experiencing an infinite looping which I can’t stop.

Note:

  • The workflow is not scheduled, so I can not cancel it in the scheduler.
  • I already modified the workflow but the loop doesn’t stop.
  • I managed to pause it by “pausing all tasks”

So the question is: how do I stop the infinite loop running in the backend ?

Any help / hint is welcome.

Thanks !

You did the right thing by pausing the workflows. Now you probably want to go to Logs - Scheduler and cancel any occurrences of that infinite workflow:

Next, resume the execution of the tasks and check for new occurences, if there are, pause and cancel again.

After that go to Settings - tab API → Infinite Recursion protection and configure a max depth for your recursive workflow.

Oh, and welcome to the club, most people (if not everyone) playing around with recursive workflows (before the infinite recursion protection was introduced) started the infinite loop at least once. :grinning:

I don’t know whether it is still possible, but in the past when people used a lot of work units because of this issue, it was possible to contact Sales/Support and get work units back (only once). But since there is infinite recursion protection now, that might no longer be the case.

4 Likes

Dear @gerbertdelangen , infinite loop of “thank you”’ !
Your reply has been very useful and instructive.
I did indeed consume all my WU in about two hrs, it was a very . . . . catastrophic experience.

But there’s something that is still not very clear to me: in my case I wasn’t scheduling any workflow, I just created one that was calling itself, so once called the infinite loop was triggered. So in this case there were no workflow scheduled, hence no possibility to cancel from the Scheduler.
I managed to stop it, but I still don’t know how I did it :sunglasses:, and I would be very happy to know how to proceed in case this happens again, and in case the Infinite recursion protection, doesn’t protect us from such rookie mistakes like mine.

Thanks again !
Bests :pray: :pray: :pray:

Thanks A, it is good to read that it helped you.

Yeah, definitely sweating at the moment. I did the same in the app of a client, luckily he laughed about it, having experienced the same thing a couple of months before (in the pre work unit age).

You must have somehow triggered and stopped it (did you by any chance use Cancel all to stop it?).

If the infinite recursion protection does not work, you can file a bug report and knowing Bubble, they will very likely reimburse you those work units.

But to be absolutely sure, you can do something like this:

Add a counter parameter to your workflow:

When scheduling the next iteration, counter = counter + 1 and set a condition to only schedule it when counter < 100 (for instance):

Or a terminate workflow when counter >= 100 is also possible:

Other things to keep in mind (depending on the importance of the backend workflow):

  • keep track of what has been processed and what not;
  • the option to restart and continue from where the workflow left off (the next iteration) in case of errors;
  • how to ensure you will be informed when something goes wrong with a backend workflow (for instance a seperate workflow with an action that sends an email when the processed number does not match the expected number).

Hope it helps!

1 Like

Dear @gerbertdelangen thanks again for sharing all that useful information. I am already implementing them.
I am also in contact with customer support to see if they can bring my WU to the value prior the infinite loop (still negotiating).

Regarding the process I followed to stop the loop: I did not press “cancel all”, what I think I did was just to pause. I deduce that because, as you can see in the img, I have now the chance to “resume tasks” (which I haven’t tried yet).

The big doubt here, is: I triggered an infinite loop, but without scheduling it. What to do in that case ? and, does the “infinite recursion protection” prevent this situations too ?

Thanks again for taking your time to reply, it has been very useful for me. If you happen to pass by Barcelona, let me know, I owe you some beers !

Hope you will succeed A.

Well actually, depening on the plan you are on (see Settings - App plan), it should be possible to see when and what triggered the workflow. If you go to Logs and fill out the date and time you suspect the workflow was triggered (see for instance the image below) you should be able to find out more (it is very detailed, so you might want to play around with advanced filtering options (link Show Advanced).

I’ll take you up on that. :smiley:

1 Like