-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
fix(query-core): handle errors that occur inside setData
method
#7966
Conversation
@TkDodo Also, currently, after the second fetch, the error will be try {
JSON.stringify(data)
} catch {
throw new Error('Data is not serializable')
} |
☁️ Nx Cloud ReportCI is running/has finished running commands for commit 82d75b7. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this CI Pipeline Execution ✅ Successfully ran 2 targetsSent with 💌 from NxCloud. |
commit: @tanstack/angular-query-devtools-experimental
@tanstack/angular-query-experimental
@tanstack/eslint-plugin-query
@tanstack/query-async-storage-persister
@tanstack/query-broadcast-client-experimental
@tanstack/query-core
@tanstack/query-devtools
@tanstack/query-persist-client-core
@tanstack/query-sync-storage-persister
@tanstack/react-query
@tanstack/react-query-devtools
@tanstack/react-query-next-experimental
@tanstack/react-query-persist-client
@tanstack/solid-query
@tanstack/solid-query-devtools
@tanstack/solid-query-persist-client
@tanstack/svelte-query
@tanstack/svelte-query-devtools
@tanstack/svelte-query-persist-client
@tanstack/vue-query
@tanstack/vue-query-devtools
More templates
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #7966 +/- ##
===========================================
+ Coverage 45.09% 63.36% +18.26%
===========================================
Files 188 127 -61
Lines 7149 4545 -2604
Branches 1604 1267 -337
===========================================
- Hits 3224 2880 -344
+ Misses 3562 1437 -2125
+ Partials 363 228 -135 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks. I adapted the message a bit
if (process.env.NODE_ENV !== 'production') { | ||
try { | ||
JSON.stringify(prevData) | ||
JSON.stringify(data) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This now throws an error when data contains BigInt. But it seems like react-query supports having BigInt in the query result. Should I create an issue for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm think it's still good to log the error because structuralSharing creates an overhead and you should likely turn it off if you have something that isn't serializable. But we should likely remove the throw. Logging is enough. Please file a PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @Efimenko for raising that PR 🙌
@TkDodo I have a question. From what I see in replaceEqualDeep
, there's nothing leading BigInt comparison to break. For example, 123n === 123n
will be true
. Is there anything else I'm missing where BigInt
could break this.setData()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
interesting. I didn't know that BigInt was referentially equal, but not json serializable. According to the documentation, we only support json serializable values in structuralSharing
, so I think the warning is still warranted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this seems to have affected a lot of upstream Wagmi users. Wonder if this should have been a breaking change. Changing from throwing to just a warning would be better though!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's "just" a dev mode warning. Why would it be breaking?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies. Didn't see this commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TkDodo – would you be open to a PR that checked for cyclic references instead of checking for non-serializable values via JSON.stringify
? Feel like a lot of consumers would be invoking query functions that return BigInt
s, so it might be a bit odd seeing these warning messages flying around when replaceEqualDeep
is also compatible with BigInt
s.
Wonder if it’s worth conveying that structural sharing is moreso only compatible with referentially stable values instead of JSON-serializable values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wonder if it’s worth conveying that structural sharing is moreso only compatible with referentially stable values instead of JSON-serializable values.
I simply wasn't aware that replaceEqualDeep
works with BigInt
- our general recommendation is to use json serializable values. If we say BigInt is supported, then why isn't Map supported, or Set, or Date, or ... it's a slippery slope. Also, in queryKeys, we actually use JSON.stringify
, so if you use a BigInt there, it will fail.
Why is JavaScript so weird that BigInt is referentially stable across values, but not serializable lol.
would you be open to a PR that checked for cyclic references instead of checking for non-serializable values via JSON.stringify?
yeah I guess that's fine. I think just calling replaceEqualDeep
itself in a try/catch would just work, too ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done! #8030
As PR is a bit stuck, this PR implements the same, with respect to the comments left in the first PR. Fix #6954