Bug Report: Cache isn't destroyed/invalidated as expected

💬 App Building
1

  • Goal: With a cached resource query, if I uncheck Cache the results of this query and rerun the query I expect the cache to be destroyed/invalidated. The bug is that I can resurrect the past cached value by using the exact same cache duration. I understand that I can manually invalidate the cache, but if I uncheck caching and run the query, I expect the cache to be invalidated automatically. Having the cache pull previous values based on cache duration is an opaque behavior that I did not expect.

  • Steps:
    1: Create a Retool DB resource query with the SQL: SELECT NOW() and enable cache, keep the default 300 second cache duration. Run this query twice to confirm in the Deubg Console that it's retrieving from cache.
    2: Now uncheck the box Cache the results of this query. Hit Run, you will see an updated time being returned.
    3: Re-check the box to re-enable cache and keep the same 300 second cache duration (keeping the duration the same is important). You will now get the time from Step 1 instead of an accurate one. You can keep repeating steps 2 & 3 and you will see the old value keep coming back.
    5: Now change the cache duration to 301 seconds, you will now see an updated time.

  • Details: I believe what's happening here is that cache is being keyed on the cache duration, so that if I choose a previous cache duration, I get that old value back. By changing the cache duration even by 1 second, you ensure you get the new value. I believe this may be related to other inconsistency issues like these:

  • Screenshots: N/A

  • App json export:
    Untitled-1.json (5.6 KB)

2

Is it possible that this is a feature and not a bug? I'm not too familiar with how caching works, but why must the existing cache be invalidated if the caching is unchecked down the line? However, even if this was intentional, maybe the devs can be swayed to make it function how you were expecting it to.

3

That's a fair point, but I would argue that the query resurrecting a cached value leads to poor experience. Consider if you and I are editing an app together. I initially had a cached query for a certain cache duration, then I uncheck it. You then come into the app and see the query isn't cached since the checkbox isn't checked (I unchecked it). So you make some changes and you re-enable the cache. Suddenly you see a historical cached value and would have no idea why that value is being returned.

4

Hi @Abhilash_Nair,

Can confirm this is a bug and I was able to reproduce with the steps you provided.

I checked our code base and it looks like the keys for the query caching are the query ID and the time duration.

I can file a bug report for this, but it would likely involve us changing our query caching infrastructure so I can't promise any timeline on that :sweat_smile:

The best current work arounds are to invalidate manually or change TTL to an unclaimed number as you mentioned that you found from your testing. With the cache expiring as well once the time limit as been hit.

I would say as well to leave the cache checked or unchecked and only toggle back and forth if it is absolutely needed. I do agree it is not the perfect developer experience that we want for examples like your comment.

1 Like