Deleting backend workflow parameters, but front-end scheduler still sends initially configured data

Hi all,

I’m making a new post for this since it’s a different topic from the original post, but related to this post

TL;DR: Front-end trigger for backend WF is seemingly still sending large amount of data for parameters deleted from the backend WF if the front-end trigger’s field is not cleared first.

In relation to my reports, I built out some workflows that trigger backend workflows, which in turn make an API call using a simple plugin I made for PDFMonkey.

I did a lot of testing with this, and for each test I was simply changing, adding, or deleting parameters for the backend WF.

Long winded explanation

Initially, I tested generating the required fields for the PDF on the front end, but it was taking too long.
Then, I changed it to send just the Things and List of Things required for the workflow, and did the computations on the backend. This turned out to be pretty slow too.
Finally, I ended up just sending the unique_id text to the backend workflow, and using “Do a search for”, which ended up being way, way faster.

For the last test, where I was only sending the unique_id as a text, I ended up deleting parameters from my backend workflow like “AllParts” which was a List of Parts. I ended up with a single unique_id that I was sending, which was the unique_id for the Report thing.

I thought this should make the backend workflow almost instant, but it turns out it was still taking forever (30+ seconds), as I could see the progress bar at the top very slowly reaching the right side of the screen.

I remembered that when removing the parameters from the backend workflow, they simply disappeared from the “Schedule an API workflow” on the front-end. I had a hunch the front-end WF was still trying to fetch and send the large list of things that was slowing it down, but even looking at the logs or the debugger, they were nowhere to be seen!
I added one of the parameters back to the backend WF, and when looking at the front-end trigger for it, it was already populated with the value present before deleting the parameter.

I ended up recreating all the related workflows from scratch, and lo-and-behold, the front-end WF was also instant as expected!

Has anyone else encountered this?

I’m going to redo any other backend workflows and the front-end WFs that launches them to ensure it’s not happening elsewhere, but it seems like strange behavior.
While not having to re-enter the value on the front-end if a parameter is deleted then re-added is convenient, the fact that it seemed like Bubble was still trying to send the data for an inexistant parameter seems like a bug to me.

This topic was automatically closed after 14 days. New replies are no longer allowed.