Changes to vars in "disable query" statement now cause queries to fire?

Support
#1

Is this new, expected behavior?

  • Given a query that has "run query automatically when inputs change"

  • And also has a "disable query" statement such as {{state1 < 3}}

  • Anytime one of the values of the variables in the "disable query" statement change, the query reruns. In this example, if state1 changes in value, the query reruns

  • Previously changes to variables in the "disable query" statement did not cause the query to rerun

This change is causing quite widespread breakdown of many of our apps. Thanks

#2

Hi @aviator22 our team wasn't able to repro this, do you mind writing directly to support@retool.com so they can help you out?

#3

I did that on Friday and included a minimal reproducible example app. Maybe the person in charge of our ticket is on break, but haven't heard back since Friday.

This breaking change is dramatically negatively affecting our primary API performance, because it's causing 10 - 20x more API calls to hit our API gateway (we use the "disable query" feature extensively to only run queries when they actually need to be run).

I've posted in the feature requests section before pleading for your team to slow down and reduce major breaking changes; it seems like that pleading has fallen on deaf ears.

#4

Hey, just want to report here that we have a ticket open for this and will pass it along in this thread when there's a fix!

Manually run graphql (relay) query + server pagination, not possible?
#5

@Kabirdas Thanks for bringing this to the team for resolution. I am also trying to use a combination of:

  • "run query automatically when inputs change"
  • "disable query" with some conditions

The main reason being that it becomes hard in larger, more complex apps to ensure all of the necessary API calls are run if you resort to manual triggers. Automatic triggers make things much more manageable, but it would be great for app performance if the disable logic was respected.

#6

Hey @davidajetter! Just want to pass along an update here.

Our team has been investigating this and it looks to be that at the moment, disable logic is respected, however, inputs to the disabled logic are also seen as inputs to the query and can trigger a rerun.

So if, for instance, your disabled logic is {{state1 < 3}} and state1 is recalculated with a value of 2 the query will be rerun regardless of where or not there are other changes (note that this happens even if the previous values of state1 was also 2 as the recalculation of the transformer is what triggers the query, not the change in value). However, if state1 is recalculated with a value of 4 the query will look to trigger, but since it's disabled it will not actually run.

We totally understand that this may not be desirable, however, since the particular behavior described above looks to have been around since 2.73.11, changing the behavior could result in breaking people's apps that are dependent on it.

If you'd like for your queries to trigger only when certain values change you can try setting it to "Run only when manually triggered" and using the "Watched inputs" field in the query's advanced settings:

#7

These decisions by Retool are baffling. There already are broken apps running right now due to this bug. Ours were. Our apps were running queries left right up and down when they shouldn't have been. That is not good.

By fixing a bug like this you're not going to break applications, you're going to fix broken applications. All your team has to do is:

  1. Notify users "hey there's this bug, you should know about it, we're going to deploy a fix on DATE. you should know that it may change the behavior of your apps"
  2. Deploy the bugfix

Additionally baffling is that your team knows about this critical bug (retool making completely unexpected API calls by error is....critical) and still doesn't mention it in your docs.

#8

Yea, it's really good that you were able to get your apps to a place where they weren't running queries as excessively.

Right now, we state in our docs that an "input" is a value inside of a {{}} tag anywhere inside the query panel (you'll notice the same behavior if you change the value of the failure condition message for example) which is consistent with this behavior and suggests that it's not actually a bug. That was something I didn't realize, not having seen queries used in that way, but it's very possible that other people have and are using it in other important ways we might not be able to predict.

Our docs team will take a look at how to at least make this clearer so that other users don't run into the same situation you had to navigate.

Edit:
Here's the updated section of our docs!