Infinite Looping and Looping Hundreds of Times

Note: If the Tulip Engineering crew patches this then the use case that my team has for it will disappear, and more importantly: I will cry.

After a lovely (and productive) office hours with @Pete_Hartnett where we discussed if infinite looping was possible, I gave it a shot. I thought that if you had triggers on a step, and you sent it to another step that had triggers that then sent it to the previous step, then you would be able to loop indefinitely.


Tulip Engineering has decided that in order to protect innocent users from looping their devices indefinitely, that there is a limit to how many how many triggers can run without human input in some form (300 in my instance). This just so happens to also prevent people that want to loop a lot (like hundreds or thousands of times) from doing massive loops. Just let me set my AWS server on fire.

I digress.

Anyways, you get this error message:

Too many triggers in a row. Cancelling remaining triggers to prevent a possible infinite loop. No more than 300 triggers are allowed to run from a single external event (e.g. button press, device output, timer). This includes triggers caused by step transitions.

Oof. :frowning:

Whelp, on to attempt 2.

To get around this I did a little bit of thinking, and after rubbing all 3 of my brain cells together, I figured out that by using the Cancel App Then Change To Step action you can bypass the 300 counter.

Turns out the Engineering Team hasn’t explored every edge case…

The quick and dirty way that I did this was by using a 30 second timer (shortest time the Tulip wizards allow) on both of my loop steps. This means that when the 300 limit is hit it stays on that screen due to not being able to perform anymore triggers, and the timer will actually hit the 30 seconds. Then, using the Cancel App Then Change To Step, you go back to your first loop slide.

Now, dear reader, if you actually read this far you may be wondering where the useful part in this is.

Me too.

There are two use cases for this:

  1. You don’t want to have to make 250 individual steps to print a form that only has minor changes. (My team’s use case.)

  2. You want to do some mega big brain massive logic that runs lots of checks over and over.

The way that I recommend for you to do either of these is to create a separate loop app. This method will not work if you have your whole Tulip program in it, as once you start, you won’t stop, or you will tie up the app for a while.

If you want to loop forever, don’t use Tulip, use something else, preferably completely custom.

If you want to loop for a large, but set amount of time, then set a logic on all of your slide connected to a new table. You must use a table because if you use an array, it will wipe every 300ish steps due to the cancel. (Thanks @aaronstone for this answer!) You will write to this table every step as a step number counter until you reach whatever either hardcoded or dynamic number of your choosing. When you reach this number, you should wipe the table, end the app, and go back to your main app and step.

To prevent a seizure it is recommended to make your two looping slides identical except for some small indicator of step change.

Congrats! You too can now loop for as long as you want! In my testing, I discovered that you can do about 6,000 table writes an hour (100/min) pretty much regardless of device. It takes around 2 minutes, 33 seconds to do one batch of writes, and 30 of those seconds are for the timer. I am sure that this process can be improved, so let me know if you can or have.

Happy Looping!

TLDR: Lower your IQ so much that you experience integer overflow.

Edit: I forgot to turn off my loop when I left work yesterday and came back to a table with 120,000 entries. I guess it works.


I’m just glad you let us come along for the journey. What an emotional roller coaster

1 Like

Glad you liked it.

The best part about roller coasters is that you always end up at the bottom! :rofl:

More show and tells are possibly in the near future…

Hey @tim.heid -

Can’t help but be a little impressed with your ingenuity. Looping has been a topics we have been looking to address more formally for years, and you took this to an extreme I don’t think any customer ever has.

A lot of our philosophy within Tulip as we evolve the product is to limit the functionality of apps to ensure stability. We would rather have a smaller scope of possible while being able to ensure anything you make will run stably indefinitely.

The community continues to push the edges of the products capabilities, and we are doing what we can to support all of the new use-case these create. Looping (especially to the scale of 120k records a day) is something that often can be a slippery slope for stability. Very quickly you would have 100M+ records, and suddenly the aggregation that could essentially run realtime takes a minute or more to be calculated.

There is working going on to natively bring looping within the product, but with the right rails to ensure users won’t shoot themselves in the foot.

Huge shoutout to the whole community pushing the edges of possible!

1 Like

for loop,maybe need wait for customer widget