I raised a bug report to Bubble about the following issue, but they closed the ticket on me saying it is a known bug, and they are not intending to fix it at the moment as they are busy.
The issue:
On the Back-end plugin when you do:
thing.get(x)
if the value is (0), then the value returned as (null) - and also if the value is (false / no) it is also returned as (null)
I know it is has been discussed in the forum in the past, but not sure how people overcome the issue, or avoid hitting the bug
given that:
Zero value is an entry by the end user while null means no entry
am passing a list of things (Number / Boolean)
Keen to hear from others how they came around this bug.
@abanostech Yeah, this one’s frustrating and you’re not alone. In backend plugins Bubble treats 0 and false as “empty” values, so when you do thing.get(x) they come back as null. That’s why Bubble considers it a known limitation rather than a bug.
Most people work around it by avoiding raw 0 / false in backend plugin data. Common patterns are using a sentinel value (like -1 instead of 0), converting the value to text before passing it into the plugin, or adding a separate flag like has_value = yes/no so you can distinguish between “unset” and “intentionally false/zero”.
It’s not pretty, but until Bubble changes how backend plugins handle falsy values, those workarounds are basically the safest way to avoid hitting this issue.
A more structural alternative is to pass the value directly as a plugin parameter instead of pulling it from the Thing with get(x), which completely bypasses the issue. It’s not pretty, but until Bubble changes how falsy values are handled in backend plugins, the safest pattern is to make value-presence explicit and design your data model so null is never overloaded to mean multiple things.
