Do When Condition is True doesn't work for Thing updated by backend workflow, UNLESS thing is Current User

[greg18]

I have a backend workflow that updates a Thing’s FieldX = “yes”. Next I want to show a popup when FieldX = “yes”.

So I use Do When Condition is True – but nothing happens.

However the action does work fine if the Thing being tracked is the Current User. Even if the Thing being tracked is the Current Page Thing, then no dice – only Current User works.

Does anyone else experience this issue?

My workaround is for the backend workflow to update not only Thing’s FieldX, but also update the Current User’s “Update” = “yes”. That successfully triggers the Do When Condition is True – which then queries FieldX on the Thing of interest and performs the intended action, and lastly resets Current User’s “Update” back to “no”.

[greg18]

Could a Bubble master like @petter or @keith please provide some guidance on what a “live connection” between the client and the database means, in Bubble terms?

I still have a challenge with Do When Condition is True (tracking a database thing) fails to trigger, and now I realize that occasionally, using the workaround (using the Current User, described in 1st post) also sometimes fails.

I think my problem has to do with the “live connection” being broken between the client and database, especially on mobile devices with an intermittent loss of cellular service.

I can’t find any documentation about this specific to Bubble, so could someone please explain:

• What does it mean for a “live connection” to exist between a client’s device and the database? As in, if the client’s device is “tracking” or “listening to” a database thing via a Do When Condition is True workflow event, and a change is made to the thing, the event will be immediately triggered on the device (i.e. not requiring refresh).
• Poor cellular/WiFi service obviously severs this live connection. When the cellular/WiFi service strength improves, can the Bubble database connection re-establish itself, or is that not possible without refreshing the page?
• Is there a max duration that a connection can remain live, e.g. 24 hours? Or could a connection remain indefinitely as long as the internet connection was not interrupted?
• Is there a way a Bubble app could detect if its live connection was lost, and/or re-established?
• As described in my 1st post, is the Current User data type more likely to have a stronger live connection to the database than other data types? Or would you expect all data types to experience a similar strength of connection?
• Would a heavier page with higher DOM count be more likely to lose its connection to the Bubble server?

Thank you very much

[greg18]

Let me elaborate:

I’m building a rideshare app. The app relies on drivers’ phones “listening” to things in the database via Do When Condition is True. Drivers are traveling along freeways with good cell service, but there are small “dark spots” without cell coverage. I notice that when driving through a dark spot, the “live connection” between the device and the server is broken (as would be expected) – but then, unfortunately, Bubble does not re-establish the connection upon driving out of the dark spot. Instead, the live connection is only re-established after refreshing the page.

Rather than use Do When Condition is True, I tried repeatedly querying the database via Do Every 5 Seconds, but that method also fails to re-establish the live connection after driving out of the dark spot. I also tried to NOT repeatedly query the database if the device is currently offline (using @gaurav’s UXTools plugin), and repeatedly query every 5 seconds ONLY if the device is online, in order to prevent queries that would fail – but that also did not result in the live connection re-establishing itself.

Any suggestions on how to automatically re-establish a live connection to the database would be much appreciated! Thank you

[petter]

Hi @greg18

I can’t claim any expert knowledge on this, but may be able to point you in the right direction to get some support from Bubble.

An http request is often called unidirectional, as it relies on the client asking the server for information, and the server sending it. The most well-known use case is to load the html and associated files for a web page. As soon as the information is sent from the server, the connection ends. Every time you need new information (by refreshing the page or loading another page) a new connection is established and then ends as soon as the information has been transmitted.

To keep a connection “live” and unidirectional, a technology called WebSockets is usually used. Unlike a regular http request, a WebSocket connection will be kept alive until it’s terminated by either the client or the server (or, as you say, by the loss of connection). WebSocket, data is continuously pushed/transmitted into the already open connection, thus making it a much more efficient way to run a dynamic web application.

You can inspect in Chrome Developer Tools that Bubble opens up a WebSocket connection when the page loads by filtering the Network traffic by the WS category:

If a connection is lost, there’s nothing built-in to the WebSocket protocol to reconnect - that’s up to the developer to set up. We can assume that Bubble has been built to try to reconnect if the connection is severed, but I don’t have any details about how exactly this works. Bubble’s support can probably shed some light on this: and it would be very interesting to hear more.

If you inspect the websocket in Developer Tools and click the Messages column, you may be able to check how the websocket behaves when you disconnect and reconnect your app.

• Is there a max duration that a connection can remain live, e.g. 24 hours? Or could a connection remain indefinitely as long as the internet connection was not interrupted?

A websocket connection can in theory last forever, but again it depends on how Bubble has set it up. I’ve successfully communicated with the server in a Bubble app after having left the page alone for a long time, but this is anecdotal so I don’t know the specifics.

As described in my 1st post, is the Current User data type more likely to have a stronger live connection to the database than other data types? Or would you expect all data types to experience a similar strength of connection?

I would expect all types to have the same connection strength, but from Developer Tools it seems that Bubble is watching the current User more actively than other page data, perhaps for security reasons. But the connection is technically the same, but it may be that Bubble initiates communication on the User more frequently.

Would a heavier page with higher DOM count be more likely to lose its connection to the Bubble server?

I don’t see any reason why DOM count would affect the connection.

Lastly, I’d encourage any devs (or @Bubble team members) with more knowledge on WebSockets to correct me or add to my info here – again I’m not an expert on this.

[eli]

Hey @greg18, I can’t answer the questions on the live connection but curious if you’ve tried the ‘trigger a custom event when the data changes’ action?

[greg18]

This is extremely helpful @petter! Thank you as always for your very thorough explanation. I hope that @Bubble can chime in too

[greg18]

Thank you @eli for this suggestion – I had never tried the “Trigger custom event when data changes” action before.

I watched these 2 tutorials but still struggled to get it working (like others), and when it did work, it would only work once per page load. It appears that “Do When Condition is True” is the more powerful tool to use, because you can specify “Do Once” vs “Every time”

But maybe I’m doing it wrong – @eli have you had success with this feature? Please share how you set it up. Thank you!

[eli]

@greg18 You have to reset the trigger each time it runs. The easiest way to do that is to have a second custom event to set the ‘trigger when data changes’ event and run it inside the event that is triggered when the data is updated