I have an app that is running for third year now, it’s a simple CRUD app where user register, create forms and then submit them for review.
It worked perfectly until last year but now i’m having performance problems when running a registration workflow.
When my users register in my app, i create some data related to them, and then redirect the users to the created record page (passed as data).
My problem is that in development it works flawessly, but when running it in production, it takes almost a minute to complete (and sometimes the signup captcha expires after submitting the signup form, since the page keeps loading in the registration state).
My temporary (but buggy solution) is to display a popup to my users saying that their account is being created and they will be redirected after the signup proccess is completed, but sometimes it never redirects (when debugging it seems that it doesn’t create every record so my user registration fails).
Here is an screenshot of my workflow, in purple the ‘create data’ actions:
Are you able to move it to a backend recursive workflow?
Add a field to the user data type ‘onboarded’ of type yes/no.
When signing the user up, set onboarded to no. Then, schedule a recursive workflow that works through all of the actions you currently have running on the page. Once they’re all complete, change user’s onboarded to yes.
If it’s important the actions have all completed before the user can access the app, add a redirect on page load when current user’s onboarded is no that takes them to a loading page saying ‘we’re setting up your account’ or something and redirect them back to the right page when onboarding is complete.
It might take a few seconds but will be more reliable.
Hi @rpetribu ! yes, i’m in the new plan, and Bubble’s version up-to-date. There are time that the workflow finishes almost instantly and sometimes that it bugs and stay loading, that’s why it’s hard to recreate/debug
It sounds like the issue youre having is timing out (the workflow stops midway through without completing). That happens when the workflow takes too long. You can break up the workflow into steps so that no workflow takes too long. For example
Steps 1-4 as normal
Schedule API workflow that runs step 5-8 and schedules a new API workflow
In the new API workflow, run steps 9-12 and schedule a new API workflow
In the newest API workflow, run steps 13-14 and make current user’s onboarded = yes
Scheduling uses WU so its better to have more actions in one workflow than less but don’t have so many that it times out.
But also, I’ve had workflows far longer than this with no timeout issues. Are you doing lots of searches within each action or something?
mmm yes, could work, seems weird because each action creates an empty record and when a relation is needed i use one of the previous actions, pic 1 (mainly because i want to avoid search actions).
I only have 1 search action and and it just grabs an int value (pic 2), so it shouldn’t generate any overload in the WF.
What takes my attention is that until last year it was working without any problems, so my first assumption is that it could be something related with the WUs or WF updates.
pic 1
