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

  • 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)

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.

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.