Custom Event Module - Boolean Logic Inversion

Bugs
1

When using a Custom Event within Bubble.io, an unexpected behavior occurs where the boolean logic of a condition is inverted. That is, a check that should return YES is returning NO, and vice versa, when used within a Custom Event.

Context:

  • The error occurs when passing a boolean value as a condition to a Custom Event.
  • When the condition is tested outside the Custom Event, the return is correct.
  • Within the Custom Event, the value is inverted for no apparent reason.
  • This directly impacts workflow logic, potentially causing critical errors in applications that rely on precise boolean checks.

Steps to Reproduce:

  1. Create a Workflow in Bubble with the following configurations:
  • Create a Custom Event named verificaPreCadastro.
  • Create a boolean condition in the main Workflow before calling the Custom Event:
Search for preCadastro (uniqueId = LocalStorage's First Item (uniqueId)) First item is not empty

* **If TRUE**, call `verificaPreCadastro`.
  1. Inside the Custom Event, repeat the same verification for debugging:
Search for preCadastro (uniqueId = LocalStorage's First Item (uniqueId)) First item is not empty
  • Add an Alert to display the result.
  1. Test the workflow:
  • When the verification is done before calling the Custom Event, the value returns correctly.
  • When the same calculation is performed inside the Custom Event, the value returns inverted.

Evidence and Screenshots:

  1. Initial Workflow - Structure showing the expected logical sequence of the flow.
    image.png

  2. Value stored in LocalStorage - Showing that uniqueId is correct.
    image.png

  3. Workflow execution on the page - Confirming the retrieval of the stored value.
    image.png

  4. Database search verification - Showing that preCadastro was correctly located (YES).
    image.png

  5. API call and workflow - Showing that the values are correct in the request.
    image.png

  6. Conditional in Custom Event - Showing that it should be triggered (YES), but it is incorrectly interpreted as NO.
    image.png

  7. Custom Event execution - Showing that the logic was inverted.
    image.png
    image.png

  8. Inverted verification - If the logic is changed (is empty instead of is not empty), the result is also inverted.
    image.png

  9. Final conclusion - The Custom Event is always inverting the boolean value.
    image.png

Expected Behavior: The boolean value passed to the Custom Event should be preserved and not inverted.

Current Behavior (Bug): Inside the Custom Event, the value is inverted, meaning:

  • YES becomes NO.
  • NO becomes YES.

Identified Workarounds:

  1. Manually invert the logic inside the Custom Event to work around the bug.
  2. Create an intermediate variable (Custom State) and use it inside the Custom Event instead of recalculating the condition.
  3. Add a short delay before calling the Custom Event to ensure values are processed correctly.

Impact: This bug can severely affect applications that depend on boolean checks for workflow control, security, and data validation, potentially causing incorrect results and unexpected actions within the system.

Request: We request that the Bubble team investigate and fix this unexpected behavior, ensuring that boolean values are maintained correctly within Custom Events.

Attachments:

  • Screenshots demonstrating the inversion of values.
  • Logs from the Bubble debugger showing the correct values before entering the Custom Event and the inverted values inside it.
  • Short video demonstrating the workflow execution with the bug occurring.

We look forward to your response and are available for any further clarifications.

2

It’s extremely likely that a single mistake in your expression is causing the issue.

3

Thanks for the suggestion! I initially thought it might be an expression mistake too, but after extensive testing, I’ve confirmed that the boolean value is correct before being passed to the Custom Event. The inversion only happens inside the Custom Event, regardless of how I structure the expression. If I reverse the logic, the Custom Event also reverses it, meaning that the issue is not the condition itself but how Custom Events interpret it.

Additionally, this workflow was working perfectly until yesterday. At the end of the day, it suddenly started showing errors in a workflow that was already validated and functioning correctly. When I began debugging, I noticed this issue, which seems to have started without any modifications on my end. Given this, I believe it could be an internal Bubble issue rather than an error in my logic.

4

Have you used the step by step debugger? That will tell you where the issue is.

5

Yes, I have used the Step-by-Step Debugger, and that’s exactly how I identified the issue.

Before the Custom Event is triggered, the boolean value is correct and behaves as expected. However, inside the Custom Event, the value is inverted for no apparent reason. If I change the condition logic (e.g., from is not empty to is empty), the Custom Event also flips the result accordingly, which should not happen.

This workflow was working perfectly until yesterday, and suddenly, without any modifications, it started behaving incorrectly. This strongly suggests that it could be an internal Bubble issue rather than a logic mistake.

Has anyone else experienced something similar recently?

6

I’ll record a video to demonstrate exactly what’s happening. This will help clarify the issue and show that the logic is working correctly before entering the Custom Event but gets inverted inside it. I’ll share it here soon.

7

In this video, I demonstrate a bug where boolean logic inside a Custom Event gets inverted. The workflow correctly evaluates the condition before the Custom Event is triggered. However, once inside the Custom Event, the boolean value is flipped unexpectedly.

This workflow was fully functional until yesterday, and without any modifications, it started behaving incorrectly. The Step-by-Step Debugger confirms that the logic is correct before the event but changes inside it.

This issue affects workflow logic, conditional actions, and decision-making processes within Bubble. I hope this video helps clarify the problem.

8

What is the storeVar action? a plugin?

Have you tried just putting the search directly on the condition of the Custom Event, and getting rid of step 2?

9

In the original workflow, the search was done directly in the Custom Event condition. I only used a variable as a reference to compare with the Custom Event and better analyze the issue.

I have already tested it the way you mentioned, and the problem still persists.

I’m running additional tests to further investigate the issue.

10

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