Cannot invalidate cache for queries in some apps

Video of the steps below, performed in realtime. [21sec duration]

I've been back and forth with Retool support on this issue for a while, in Live Chat (which was removed from our paid Team plan not long ago), email support, and in the forums.

I'm trying again here because it's so obviously not working across a number of our apps. Previous attempts to raise it in the forums would be intermingled with other reports of the similar or even same result (invalidation not working) but with different symptoms / preconditions / etc. [example 1] [example 2]

Not having control of cache invalidation severely limits the type of performance and functionality we'd otherwise expect to be able to control.

I'm able to invalidate the cache in this manner for a similar query to the same endpoint when creating a new barebones app, and for this and previous unrelated issues the troubleshooting line prescribed has sometimes been: "What if you just recreate your entire app?" For various reasons I'd like to avoid doing that (loss of release history, for one), and I'd guess other builders & maintainers of long-established apps would feel similarly. So it seems like app functionality in this regard tends to degrade over time, which is a problem for non-trivial tools.

Steps in video:

  1. Run query for the first time via blue button in Code drawer query details: see expected output in console:

  1. Run again immediately after: see expected "from cache":

  1. "Invalidate cache" from the query's triple-dot options; see the console reflect that. Note that the POST returns 204 and shows the expected request payload sent:




  1. Run query again and see unexpectedly that it's still returning "from cache":

I have no idea what you've tried or haven't so hopefully you haven't tried one of these:

  • using cache.delete(). docs here
caches.keys().then(function(names) {
    for (let name of names)
        caches.delete(name);
});
caches.open("v1").then((cache) => {
  cache.delete("/images/image.png").then((response) => {
    someUIUpdateFunction();
  });
});
  • using .getRegistrations() to manually unregister all service workers, some of which can be responsible for caching resources
if ('serviceWorker' in navigator) {
   navigator.serviceWorker.getRegistrations()
   .then(function(registrations) {
      for(let registration of registrations) {
         registration.unregister();
      }
   });
} 
  • location.reload(true). force the page reload to clear the cache and reload it

Hi @bobthebear, these approaches seem focused on clearing my browser's local cache(s), whereas Retool's query caching happens on the server. So the response is coming back cached when it shouldn't be.

Regardless, thank you for the suggestions. I tried them — in some cases replacing the inner operation with a console.log as a dry-run, out of precaution — and either they had no effect or would not have had any results to operate on.

I am encountering the exact same issue myself.

Initially, the cache invalidation mechanism functions adequately across all queries. However, over time, it begins to fail on individual queries, leading to a rapid proliferation of broken queries.

The issue seemed to dissipate temporarily after duplicating the application, but the respite was short-lived. Repeatedly cloning the applications on a weekly basis is not a viable solution either, as they rely on each other's unique identifiers (UIDs), and the client requires stable links to the applications.

This bug poses SIGNIFICANT ramifications for the project, particularly because the client demands a highly responsive application, a requirement challenging to meet without effective database caching in our current setup, thus becoming an obstacle that prevents the program from being released.

I hope that this problem will be solved as soon as possible.