We had previously restricted scheduled API workflows from scheduling themselves (or scheduling another workflow that then scheduled itself). This restriction is now removed.
Recursive scheduled workflows can be useful in situations where you are processing an unknown quantity of data that might be quite large. For instance, the following workflow will make sure every Thing in your database has been processed within 7 days:
Processing data this way is generally a better approach for large quantities of data than using the “Schedule API Workflow on a list” action. A brief comparison:
|Scheduling on a list||Scheduling recursively|
|Workflows may overlap||Workflows run one at a time|
|No way of knowing when all workflows are done||Workflow can check if there is more data to process, and do something else if there isn’t|
|Limited by the time / capacity it takes to search for the list and schedule all the items (max 5 minutes)||Can continue indefinitely|
|Faster and simpler for short lists (< 50 - 100 items)||More reliable for long lists|
|Can burn through a lot of capacity if workflows run in parallel||Capacity usage is limited to one workflow at a time|
A couple notes:
- In order to avoid maxing out your app’s capacity, I recommend starting with a 5 second gap before scheduling the next item in the list. You can then shorten this gap once you see what the capacity impact is.
- If you make a mistake and create an infinite loop that does not look like it will ever end, you can end it by manually deleting the next scheduled run in the Logs → Scheduler tag. You can also modify or delete the API workflow itself: deleting or changing the workflow won’t remove a scheduled item from the list of scheduled tasks, but when it comes time to run that item, Bubble will use the updated workflow or do nothing if it has been deleted.
- If things get really bad, you can pause and resume all scheduled workflows for your app using the new “Pause tasks” button: