If it’s not a list, bubble doesn’t let you use the ‘plus item’ function.
I’m 90% sure this is a bug because I have an app where the same workflow I created a few months ago behaves differently. But maybe I’m missing something.
I haven’t done much with lists like this so not my area of expertise, per se. Two ideas to test though: 1) try adding a delay between step 1 and step 2 and see if that changes things. 2) try each step by themselves to ensure you get the expected result.
If those don’t shed light on what’s going on, I’d say it’s probably a bug and worth submitting.
It looks like the actions are running simultaneously. When the debugger reaches the 2nd step in your sequence, it shows that the state is still empty, so I changed the workflow to force the order by scheduling the second step 0.1 second after the first step, and it works. Check it out.
When the :plus item adds an item, like most list operations it causes the list to discard duplicate items.
So to produce an end result of just (no), it would likely have tried to add (no) twice.
@romanmg I’m thinking it is a timing issue, Page Load might be triggering the workflow before the checkbox gets its checked status. Because if your suggestion is correct, the workflow is ignoring one of its own steps, which is of concern! Haha.
Edit - I tried it step by step, on the second step it shows the list as being empty, so I think @romanmg is partially correct …
step1 get the custom state value : empty list
step1 add the (yes) to the list
step1 set the custom state new value: (yes)
step2 get the custom state value : empty list hasn’t seen the new value from step 1.
step2 add the (no) to the list
step2 set the custom state new value: (no)
When I put a pause between the steps, the state goes from empty to (yes) to (no), which means either of:
The workflow can’t see updated custom states it has updated.
Or the pause is not preventing the step execution, just our seeing its result.
@rushabh can you explain how a list of (yes,no) is useful in your app?
@romanmg Thanks for figuring that out. But your answer makes me very uneasy.
I understand that workflows have no order in which they run (based on Changing the order of workflows ), but my assumption has been that actions within a workflow have a defined order. And my whole app has been built with this assumption.
In fact, I have had this same workflow in my app for multiple states. And for all of them it works as expected (populates with yes,no), but the behavior seems to have changed for workflows I created after ~1 month ago.
Are you confident that actions running simultaneously is by design?
I use the list of (yes,no) in several places. For example, people on their profile state whether they can only host fixed dogs (yes = they can host only non-fixed, no = no preference).
The search by default shows all users where that field is yes & no (hence state is yes,no). But if you state in your profile that your dog IS NOT fixed, then the search excludes people who said they can only host fixed dogs. So when the page is loaded, that state is only populated with no.
So, there are a few discussions about this around the forum regarding sequencing, when Bubble waits to run an action, when it doesn’t, etc. Apparently there are a few factors. @mishav studied the sequence closer than I did, so there might be something more going on than my theory, but I think this is something you’ll need to test more, especially when these lists start to grow on you and other stuff is happening on the page.
Other than that, I read your use case, and I feel like you can restructure a bit. Instead of a list of yes/no’s, why not 1 yes/no for if the User can host 1 type of dog, and another yes/no for hosting 2nd type of dog? If they can host both, both will be yes. If only one, then only one will be yes. The default search would not include a constraint on either yes/no fields to include everyone. If the user’s profile says that his dog is not fixed, then the search would include a constraint to those whose “will host not fixed” yes/no field = yes.
The reason I use a list for this is that I don’t have to change the RG source depending on the situation. I.e. the RG source is 'Do a search for users where host_fixed_only contains my_custom_state. Otherwise I would have to add/remove a constraint depending on the user.
But there are definitely opportunities to optimize further. Perhaps I’ll book a consult with you in future and you can help me with that =)
