Since June 13th, a “Search for” condition gives FALSE by mistake

Hi, a particular workflow which has always been fine since I create it in March, stopped working in the last 2 weeks despite I haven’t updated my app in more than a month.
I opened a ticket but I’m posting the problem here hoping that someone can help.

Before I can detail the bug, I need to explain how my app works.

I built loyalty system for small shops that works as follows.

  • At the counter of a shop (“Merchant”), a tablet (DEVICE 1) welcomes clients (“Shoppers”) asking them to tap their mobile phone number in order to check-in.
  • The cashier, via his mobile phone (DEVICE 2), assigns 1 point for each EUR spent.

Both DEVICE 1 & 2 are logged to the app via the same user (the one of the Merchant) but they show different pages.

If it’s a returning Shopper, a thing is created in a table named “Transactions” with label “Purchase” showing the points assigned.

If it’s a new Shopper in that shop:
a) like in the previous case, a thing is created in table named Transactions with label “Purchase” showing the points assigned;
b) another thing is created in table Transactions with label “Welcome” assigning 5 welcome points;
c) a thing is created in table “Phone numbers”
d) an SMS is sent to the Shopper that checked-in
e) a thing is created in table “SMS usage”.

The problem is that since June 13th, steps d) and e) above do not happen anymore for all the shops using my app. Some details:
• a) and b) are created by a workflow that does not have problems, they always get created
• c), d) and e) are created by an API named “assign-points”
• c) only runs if the phone number is not already present in table “Phone numbers”, it always works.
• d) and e) are set to run only if in table Transactions there is just 1 thing having:

  • the relevant phone number
  • the code identifying the shop
  • type = “Purchase”
    This means “send an SMS if it’s the first time that this shopper checks-in in this shop”.

Here’s a screenshot of the “assign-points” backend workflow:

Here’s a detail of step e)

The bug is that the condition returns FALSE when instead it’s TRUE.

Please note that:
• It is not a problem with the api of the SMS provider. Both d) and e) don’t fire and they have the same condition. If d) had a problem then e) would still fire but this is not the case.
• I couldn’t recreate the problem:
o I tried to create a brand-new user (i.e. a merchant). Tried to check-in with my personal phone number and it worked.
o I tried to log in as one of the Merchants experiencing the problem, tried a check-in with my personal phone number and it worked.
• I’m sure that the problem is there because I downloaded all Transactions, Phone Numbers and SMS Usage and saw that, since June 13th, all transactions labelled “Welcome”:
o do not have a corresponding thing in SMS usage (step e) failed) and looking at the platform of the SMS provider the SMSs were never sent (step d) failed)
o do have a corresponding thing in Phone numbers (step c) succeeded)
The only exceptions to this bug appeared after June 13th are the tests I did. A real mystery to me.

This is serious problem for me as, without sending an SMS to the new Shopper, his onboarding cannot take place. I thank in advance if anybody can help.

Hi @gianluca1,

Hard to say for sure if this is the issue, but one thing to carefully examine and consider…

If any step of the workflow assumes that a prior step has finished executing, then you might be encountering a so-called “race condition”.

To guarantee - i.e. force - a particular order of execution, some combination of referencing the Result of step x and/or the use of Custom Events can be used.

You might want to carefully read this section of the manual on workflows for some helpful insights.

Good luck!


Thank you, I guess this is unlikely to be the reason for the problem because the search condition giving FALSE by mistake is searching among things that were created quite some time before this workflow “assign-points” is started. In particular:

  1. the Shopper on DEVICE 1 checks-in on the tablet and a) and b) are created via WF#1
  2. after a few seconds the cashier, on DEVICE 2 via WF#2, assigns point. This triggers the WF#3 (i.e. “assign-points”) that searches a).

What more all the sequence has always been working up to June 13th when suddenly it stopped working despite no changes were done on my app. I believe that some changes were done on Bubble’s platform that caused the problem.

In any case your suggestion is super useful. I will re-check every single step of each WF and try to change the logic to make sure 100% I don’t have any “race-condition”.

I solved! The issue was not due to a “Search for” condition giving FALSE by mistake but was instead due to step 4 in the “assign-points” workflow. It is using a plugin named “Random String Generator” from @Yinka. The plugin must have had some kind of problem and it was simply stopping the execution of all the following steps. Now I upgraded the plugin and the problem solved (thanks for the upgrade @Yinka ).

I didn’t know that the failure of one step prevents the execution of the following steps.
@allenyang @emmanuel you might want to consider adding an alert for this kind of situations so that the admin of an app can take a prompt action.


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