How is this even Possible? - Option value in logs, doesn't exist in app

[boston85719]

I reported a bug to support on March 27 about an issue with backend workflows not setting the correct option value. In the logs I could see the option that was set, in the database, I can see the same as what is in the logs, but in the workflow action is set to a single value (ie: not dynamic) as this is a status…in the WF action is set to be pending, but in the logs it showed as completed.

Bubble support was quick to respond and on March 30th confirmed that they do see the issue, but instead of sending it up to engineering for a fix, they asked for step by step instructions on how to reproduce…which, shouldn’t the logs suffice, plus this is a live app with real money involved, so the step by steps would require Bubble support to make payment.

Either way, as I don’t have all the time in the world, I was not able to respond quick enough to support (3 days) until they closed the ticket and marked it as resolved, which of course it was not. Now, since engineering was never informed, the issue persists, and the client who owns the app made me aware of the issue still causing problems when their service professionals are providing the service to clients, details required are not visible in the app.

So, looking into the logs now, for the booking that had the issue I see something that I just can not wrap my head around, and it is ALARMING to say the least.

Now, instead of just having the incorrect option value, it is setting the value to one that doesn’t even exist in the option set itself.

Logs show the value for status_option_task to ‘finished’

WF action shows that it should be ‘pending’

Option set values do not even include ‘finished’

There is not even a deleted option in that set. No values had their names changed. No attributes have the value of ‘finished’

What is happening with this? What is going with Bubble and data integrity? Are they using option set values from somebody else app?

And who is it that is the Product Manager for Support?

[Jici]

I think, but really not sure, that you are not checking the correct option set or action. Did you click on the “Make changes to Booking” from the logs (that is also showing “Pending” …?!)?
But this is very strange if you checked the right stuff

[boston85719]

Yes, I clicked the action from the logs, and yes I checked the correct option set

Absolutely no idea why the search filter when I use ‘task’ shows the values for Option Booking Status

[Jici]

This is like if this found a deleted or renamed option set and it’s always set on that. What if you delete the field and set a new one? (However, I totally agree that it’s a incredible bug…)

[Jici]

Another question, do you use different versions? Maybe there’s a conflict between them?

[boston85719]

@Jici

if this found a deleted

No deleted options, as can see in the screen shots, there are none…usually at top of the option set you can see light grey ‘deleted options’ and click that so you could restore it.

@Jici

renamed option set

Possible, but still doesn’t explain why the wrong value is getting set.

[boston85719]

Main development version and Live version Only

[Jici]

I hope that you will not have “expected behavior” for this bug if you create a ticket support!

[georgecollier]

@Jici

renamed option set

This. The logs are likely showing the option set ID. If you go to the app, then open dev tools and console.log(app), open the option sets and you’ll find the ID of the option set. See here for Bubble’s option sets:

The bold text is the option set ID, and the text on the right is the display along with any attributes.

Basically, yeah it appears different in the logs, but everything’s correct so nothing to worry about.

[nico.dicagno]

It might be because you renamed the option set. It is a ridiculously annoying quirk with Bubble, but when you rename an option, logs will keep using the original name of the option no matter what. This also happens with database fields.
I really dislike this. I generally delete fields/options instead of renaming them to avoid confusions down the line (in pre-live development ofc)

[boston85719]

By the way, this happening in another workflow as well…same option set, different value to be used in the WF action and again, different value can be seen in the logs

I originally shared the video then saw a users email and can not remove so I deleted video from this post.

[Jici]

Yes exactly what I just found too. The ID will remain the original info entered. If you modify it, it will remain but display will be updated. In a no-code world… this shouldn’t happen.

[boston85719]

Am I missing something here?

I opened editor, went to the option set, clicked developer tools, selected console, but I do not see anything like what your screen shot shows.

[georgecollier]

Type console.log(app) in the app run mode, not the editor

More info here Bits of your Bubble app you might not know are public

[boston85719]

Looks like some names were changed, likely 18 months ago.

So, no Bug, just terrible LOGS…WHEN OH WHEN ARE THEY GOING TO FIX THE LOGS SO WE CAN USE THEM???

I feel like every bug report I’ve made in the last 3 months has been because the logs just don’t do what we need them to do.

Thanks @Jici @nico.dicagno and @georgecollier for the help.

[georgecollier]

@boston85719

So, no Bug, just terrible LOGS…WHEN OH WHEN ARE THEY GOING TO FIX THE LOGS SO WE CAN USE THEM???

It’s the intended behaviour

[nico.dicagno]

Yes its honestly a destructive sneaky little thing.
I’ve seen apps that renamed the majority of their fields. Logs are already an absolute pain to work with, and on top of that log fields names are also mismatched with datafields?? Absolutely impossible to bug hunt.

And ofc people will rename their fields… as they learn bubble/programming they will find and experiment with naming conventions. But this will absolutely BUTCHER the logs. And there is no way round it except renaming your fields back to the terrible ones you first stated, or (lol) create new fields and copy over your entire database to the new ones.

[sudsy]

@boston85719

So, no Bug, just terrible LOGS…WHEN OH WHEN ARE THEY GOING TO FIX THE LOGS SO WE CAN USE THEM???

FWIW, I agree the logs should show only the display name. Given that the id is generated and used internally, it seems that never exposing it to the user would be best - not even as an option for the data API. That said, however, it seems like it’d be trivial to put the display name in parentheses after the id in the log view.

Also, a somewhat related heads-up… Don’t ever give an option set the same name as a custom type. Most folks wouldn’t do so intentionally, but the editor doesn’t prevent it, so it’s something to be aware of.

[boston85719]

@sudsy

Also, a somewhat related heads-up… Don’t ever give an option set the same name as a custom type. Most folks wouldn’t do so intentionally, but the editor doesn’t prevent it, so it’s something to be aware of.

I always label option sets with the word Option at the beginning so as to differentiate between data types if there is a chance the names may be similar. I’ve been doing that since the introduction of Option sets as only up to recently did Bubble stop grouping and sorting option sets and data types together.

I teach all my students to do the same thing, or something similar like using OS instead of Option

[ihsanzainal84]

I will always prefix mine with (Set).