I have a backend workflow where I’m post-processing a list of items through multiple steps (we’re matching employees to a job based on skills, schedule, other qualifications).
A simplified view of the architecture is this:
create a new “job” object, with a List field “qualified employees”
Add all the possible employees to the List of qualified employees
run through different relevant qualifications and use “remove list” to remove disqualified employees
BUG HERE - at this point, I run an “add list” to add “favorite employees” (who should be added after all the remove list steps because we ignore the qualifications for the favorite employees)
^In this bugged step, applying the “add list” causes the original list to reset completely, and only the list of favorite employees are still present - I confirmed this by (painstakingly) removing every single change in the list one by one to identify why expected employees were disappearing
Is this expected but poorly documented behavior, or have I uncovered a strange bug? The only way I found to get around it was to add a second list item on the “job” object to add the favorites into and then process them later.
@fede.bubble I also submitted a bug report but flagging here in case someone else has encountered similar behavior
EDIT FOR NEW VIEWERS:
Bubble support confirmed that the issue stems from using “set list” and “add list” on the same element in the sequence. Previously, step 1 in this workflow was an “add list” and when I was replacing it with a new action, I changed it to “set list” (without changing the later steps 2-4 which had previously worked). Apparently, there can be issues with using these actions together, so the recommended process is to begin with “add list” instead of set on the initial empty object
Another option might be to add only one list but to refine your search to add one list of qualified employees but only those who match the full criteria. This avoids adding a list, removing people, then adding more people (the favourites). It’ll be more WU efficient.
It wasn’t human error. Bubble support confirmed that because the initial action in step one was “set list” rather than “add list”, this caused the later “add list” to perform like “set list” - horribly undocumented behavior, but that was the cause
Also, I can’t just do it as a search because I’m checking against a list of optional yes/no fields, and there’s not any way in a bubble search (that I’ve found) to make specific yes/no checks optional - We’re checking for cases where if the job parameter is “yes” then the employee parameter must be “yes”, but if the job parameter is “no” then the employee parameter can be “yes” or “no” → “ignore empty inputs” doesn’t work because the job parameter value of “no” isn’t considered empty
I spent 5 hours testing each step individually to isolate the cause, it was in fact this step and the undocumented behavior in how “set list” interacts with a later “add list”
Chained actions in a workflow, only way to guarantee the writes to the DB happen serially rather than parallelized (which can cause overwrites). Atrocious for WU but this particular action is infrequent so I was happy to have something that just works
I’ve experienced similar issues before with poorly named actions. “Clear list in a repeating group” makes it sound like it would be emptying the RG, but it actually just resets it to its original state (including non-empty values if you set it with default data). This case is actually documented correctly, but the name of the action is misleading
For context, this serialized workflow had been working for months, it was only when I was making some other changes to an unrelated aspect that the issue was introduced - I replaced the very first step in the with a “set list” instead of an “add list” and that caused the downstream issue indirectly
I assume you mean chained by conditional expressions containing a piece of the previous step, or each write to the same record wrapped in custom events.
I could be wrong, been a while since I had to troubleshoot concurrency issues in the backend, but updates to a record are not guaranteed to happen in sequence otherwise.
