Handling Persistent Storage Overflow with TanStack Query and tRPC/dynamic keys

[hirbod]

Issue Description:

Summary:

We are currently implementing tRPC and TanStack Query in our project, utilizing the experimental createPersister feature. While the integration works well, we've encountered an issue with the accumulation of outdated data in the storage, which TanStack Query does not automatically delete.

Detailed Explanation:

Our implementation includes a user.byUsername route in tRPC with a fixed query key structure (user, byUsername, and the username as input). When a username is changed in the user.byUsername endpoint, the query key also changes accordingly (or just another profile was opened with a different username). This results in the persistence of both the old and new entries in the storage. Since TanStack Query no longer calls the old key (unless it happens randomly someday), it remains indefinitely in the storage. This data persists until it is manually deleted, or the storage is cleared by the system due to space constraints, or further writing to AsyncStorage/LocalStorage is restricted.

Core Issue:

The main concern is the unmanaged growth of old data in the storage, leading to potential overflow and inefficiency. The current behavior of experimental_createPersister only writes cache to memory when it is accessed, which means old, unused entries are not addressed.

Suggested Solution:

A potential solution could involve TanStack Query performing a cache validation process on boot. This process would scan through the cache to identify and delete old, expired keys. However, this approach might need to be carefully designed to avoid significant performance impacts, especially for applications with large caches.

Request:

We are seeking advice or a potential update in TanStack Query to handle this scenario more efficiently. An automated mechanism to clean up old, unused data in the storage would greatly enhance the usability and reliability of the persistence feature, especially for applications with dynamic query keys like ours.

[TkDodo]

@DamianOsipiuk we need to think about this, too. It's not trpc related. For example, if you do search queries where the search term is part of the input, we will persist it under the key of what you searched for, but it will never be restored, and thus never cleared from storage, unless you explicitly search for the same thing again 🤔

[DamianOsipiuk]

We could add some sort of getIterator for the AsyncStorage interface, which then could be leveraged by invoking some sorts of cleanup/gc function returned by createPersister.
It will iterate over the cache removing expired/busted items based on prefix, where we could use portion of the restoreQuery logic without actual restoration.

But this would also have to be explicitly called by users, if we do not want to hook to query-core

[hirbod]

I believe it's reasonable for the user to call this during app boot. However, implementing a general handling could be more challenging. For instance, localStorage doesn't have a .getAllKeys method (although this can be worked around). On the other hand, React Native's AsyncStorage does provide a function for it.

[TkDodo]

But this would also have to be explicitly called by users

I agree this sounds like a good approach to have users call something like that on startup

[hirbod]

Here is a very easy solution I've implemented.
https://gist.github.com/hirbod/bc1538990d1b47419c3cb1f6622f7625