Skip to content
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

useQuery fails to resolve ssr renderPromise due to JSON.stringify reordering #11798

Closed
cclp94 opened this issue Apr 21, 2024 · 7 comments · Fixed by #11799
Closed

useQuery fails to resolve ssr renderPromise due to JSON.stringify reordering #11798

cclp94 opened this issue Apr 21, 2024 · 7 comments · Fixed by #11799
Labels

Comments

@cclp94
Copy link

cclp94 commented Apr 21, 2024

Issue Description

We found a bug in production where the lookupQueryInfo() method would consistently not render a SSR component after calling renderToStringWithData.

Upon investigation, we found that the query was being executed and the result should have been available. However, a second QueryInfo would be registered instead of recovering the resolved one. This is due to the JSON.stringify method switching the order of attributes when looking up the Map (Check screenshots).


Screenshot 2024-04-19 at 4 27 10 PM Screenshot 2024-04-19 at 4 28 15 PM

I noticed the utilities package already provides a canonicalStringify which would fix this issue.

Link to Reproduction

https://github.com/apollographql/apollo-client/blob/main/src/react/ssr/RenderPromises.ts#L140

Reproduction Steps

No response

@apollo/client version

3.8.3

@phryneas
Copy link
Member

That's interesting - are you passing different variables in different situations here?
I don't think that Apollo Client ever touches variables in a writing manner, and JSON.stringify would always stringify things in the object order.

That said, using canonicalStringify absolutely makes sense here. I'll prepare a fix.

@cclp94
Copy link
Author

cclp94 commented Apr 22, 2024

Amazing, @phryneas. Thank you for the fast response.

That's exactly what I found weird about it. We don't pass different variables to it (although I guess the react re-rendering recreates the objects/variables that are passed when the functional component gets re-executed). I tried getting JSON.stringify to reproduce the issue in isolation but couldn't.

@cclp94
Copy link
Author

cclp94 commented Apr 22, 2024

I am also willing to make the contribution if you are short on time. Let me know.

phryneas added a commit that referenced this issue Apr 22, 2024
fixes #11798
This ensures that queries with variables of equal contents, but different order, will be handled the same way during `renderToStringWithData` SSR.
It also replaces a hand-written Trie implementation with the `Trie` dependency.
@phryneas
Copy link
Member

I was already in the middle of the PR :)

Could you try this build and report if it fixes your problem?

npm i @apollo/[email protected]

@cclp94
Copy link
Author

cclp94 commented Apr 22, 2024

I just tested it and it seems to fix our issue. Thank you for the help.

phryneas added a commit that referenced this issue Apr 24, 2024
…ie` (#11799)

* `RenderPromises`: use `canonicalStringify` to serialize data, use `Trie`
fixes #11798
This ensures that queries with variables of equal contents, but different order, will be handled the same way during `renderToStringWithData` SSR.
It also replaces a hand-written Trie implementation with the `Trie` dependency.

* Update .changeset/early-pots-rule.md

Co-authored-by: Jerel Miller <[email protected]>

---------

Co-authored-by: Jerel Miller <[email protected]>
Copy link
Contributor

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Client usage and allow us to serve you better.

Copy link
Contributor

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
For general questions, we recommend using StackOverflow or our discord server.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 25, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants