New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Devtools + async persistence + custom queryKeyHashFn doesn't work #6958
Comments
Also works fine with the |
Here's a reproduction: Works on the first load, but not on the second. Doesn't display any queries. In my actual case after a few reloads the devtools crash. Moving devtools under WaitForRestore resolves it in the reproduction, but not in my actual app for some reason (no idea if it's the amount of data or latency from queries being triggered). Edit: I understand the difference now. One of my queries defines a custom |
Seems like getStatusColor is called with an undefined query. Fwiw, just adding a check for whether query is defined is a quick fix for the problem. The root of problem is likely somewhere here:
|
Seems like the culprit is: Which calls query/packages/query-core/src/utils.ts Line 88 in 8104a40
This line in particular: query/packages/query-core/src/utils.ts Line 103 in 8104a40
Shouldn't hashing happen only at the time of fetching to make sure we can trust the hash to be exactly what params were passed to the queryFn? Wouldn't this cause issues and race conditions all over the app (outside of devtools)? Seems like Devtools just highlights the issue because it calls find against all queries, but this could happen in userland as well – active query changes e.g. queryKey, optimistic update tries to find relevant queries, find method rehashes data of a different query, and we end up with a corrupted cache. For devtools in particular, it's a problem, since it rehashes a cached key, which may be generated by a useQueryOptions Wdyt @TkDodo? Seems related to #6103, but understand why it's been difficult to reproduce. |
I've tried your reproduction but it doesn't crash for me. What do I need to do to make it crash please? |
queries are stored according to their hash. in order to find a query by queryKey in the cache, we need to hash the key and then compare it. This is indeed troublesome if different hashing functions are used per query. Since I think the recommendation would generally be to setup query key hashing globally if you need to. |
Load it once (make sure devtools are open), and then refresh the preview window. It will not load up any queries (cached or subsequent) into the devtool. The toggle devtools button will noy work. I haven't done a reproduction on the "crash", by which I mean the devtools don't load at all (even empty). But it usually happens after the third refresh, but may require more queries. |
Well, this approach seems to still cause issues (as expressed in the related issue). Since active query queryKey can change (e.g. filters change), then rehashing the key arbitrarily can cause race conditions, as well as is not the most performant solution on larger caches. I posit that there's still absolutely no valid reason the rehash a cached queryKey. |
I'm not sure I understand that, we're not "re-hashing" anything in the let's say we have the following cache entries:
all these 3 queries are stored in the cache, and are already hashed. let's assume
now when the user says something like: Please let me know where you think this can cause race conditions because I don't really see it. |
Ah, you're absolutely right. I misunderstood the code / was thrown off by the console logs – sorry for my misunderstanding. I thought it was calling So, the problem really only exists on Devtools level.
To fix, we could just fall back to Alternatively, a more elegant fix potentially would be a function to find a query in the cache based on the queryHash rather than the queryKey. But not sure if that should exist only on the devtools level or would also be useful in query-core. I updated the reproduction, and it should break more reliably now (refresh the preview and check the console + query list will be empty even though the counter at the top shows otherwise): https://codesandbox.io/p/devbox/musing-williamson-vgj34y |
this can be achieved with |
Is there a reason why Devtools don't use that? 🤔 |
I guess not. It's a more low-level API, but if it fixes the issue, please feel free to PR the change. It should also be faster. |
Describe the bug
When using both persistence and a custom
queryKeyHashFn
, the DevTools will crash on initial load with error:Busting the cache on each load "fixes" it. And so does removing the custom
queryKeyHashFn
.Just upgraded from v4, and this worked fine then. I also tried with a createSyncStoragePersister, and that works completely fine as well.
Your minimal, reproducible example
https://codesandbox.io/p/devbox/musing-williamson-vgj34y?file=%2Fsrc%2FApp.jsx%3A90%2C29
Steps to reproduce
queryKeyHashFn
to queryClientdefaultOptions.queries.queryKeyHashFn
. E.g. return(queryKey)=>hashKey(queryKey) + "_test"
It works when there's no cache being loaded. It doesn't when something is loaded from the cache.
Expected behavior
Devtools should support a custom queryKeyHashFn with async persistence.
How often does this bug happen?
Every time
Screenshots or Videos
No response
Platform
Macos, latest chrome
Tanstack Query adapter
react-query
TanStack Query version
5.22.2
TypeScript version
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: