apollo-client: bug: `useQuery` with a fetch policy of `standby` causes SSR to hang
Intended outcome:
Render a component that contains a useLazyQuery
hook.
Actual outcome:
The rendering process hangs even if the component is returned.
How to reproduce the issue:
Clone the following repo: https://github.com/simplecommerce/meteor-graphql-app
Make sure meteor is installed and execute meteor npm install
and meteor run
.
It will run on port 3000.
Load the site, it should render with no issues. It runs on version 3.4.7
of @apollo/client
.
Now stop the instance and execute meteor npm install @apollo/client@3.5.4
and run the instance again.
Now try to load the site, it will hang and eventually time out.
If you go to https://github.com/simplecommerce/meteor-graphql-app/blob/master/imports/ui/Info.jsx
and place a return "test";
before the useLazyQuery
it will render, but if you place it after, it won’t.
I tried to console.log
the variables, loading, error, etc, and they all seem ok at first glance, so something else seems to be causing it to time out or hang.
I also tried versions 3.5.0 up to 3.5.4 and the same issue occurs.
Versions
System:
OS: Linux 4.15 Ubuntu 18.04.1 LTS (Bionic Beaver)
Binaries:
Node: 12.15.0 - ~/.nvm/versions/node/v12.15.0/bin/node
npm: 6.13.4 - ~/.nvm/versions/node/v12.15.0/bin/npm
npmPackages:
@apollo/client: ^3.5.4 => 3.5.4
apollo-server: ^2.25.2 => 2.25.2
About this issue
- Original URL
- State: open
- Created 3 years ago
- Reactions: 21
- Comments: 18 (4 by maintainers)
Commits related to this issue
- chore: do not pin @apollo/client in the canarist rootManifest I'm not sure why we did in the first place, but for now we want to pin @apollo/client in the regular dependencies to 3.4.17 because of: h... — committed to xing/hops by ZauberNerd 2 years ago
- fix: pin @apollo/client to 3.4.17 due to SSR bug in useLazyQuery https://github.com/apollographql/apollo-client/issues/9108 — committed to xing/hops by ZauberNerd 2 years ago
- fix: pin @apollo/client to 3.4.17 due to SSR bug in useLazyQuery https://github.com/apollographql/apollo-client/issues/9108 — committed to xing/hops by ZauberNerd 2 years ago
- fix: pin @apollo/client to 3.4.17 due to SSR bug in useLazyQuery https://github.com/apollographql/apollo-client/issues/9108 — committed to xing/hops by ZauberNerd 2 years ago
- fix: pin @apollo/client to 3.4.17 due to SSR bug in useLazyQuery https://github.com/apollographql/apollo-client/issues/9108 — committed to xing/hops by ZauberNerd 2 years ago
- fix: pin @apollo/client to 3.4.17 due to SSR bug in useLazyQuery https://github.com/apollographql/apollo-client/issues/9108 — committed to xing/hops by ZauberNerd 2 years ago
- chore: do not pin @apollo/client in the canarist rootManifest I'm not sure why we did in the first place, but for now we want to pin @apollo/client in the regular dependencies to 3.4.17 because of: h... — committed to xing/hops by ZauberNerd 2 years ago
- fix: pin @apollo/client to 3.4.17 due to SSR bug in useLazyQuery https://github.com/apollographql/apollo-client/issues/9108 — committed to xing/hops by ZauberNerd 2 years ago
- chore: do not pin @apollo/client in the canarist rootManifest I'm not sure why we did in the first place, but for now we want to pin @apollo/client in the regular dependencies to 3.4.17 because of: h... — committed to xing/hops by ZauberNerd 2 years ago
- fix: pin @apollo/client to 3.4.17 due to SSR bug in useLazyQuery https://github.com/apollographql/apollo-client/issues/9108 — committed to xing/hops by ZauberNerd 2 years ago
- chore: do not pin @apollo/client in the canarist rootManifest I'm not sure why we did in the first place, but for now we want to pin @apollo/client in the regular dependencies to 3.4.17 because of: h... — committed to xing/hops by ZauberNerd 2 years ago
- fix: pin @apollo/client to 3.4.17 due to SSR bug in useLazyQuery https://github.com/apollographql/apollo-client/issues/9108 — committed to xing/hops by ZauberNerd 2 years ago
- chore: do not pin @apollo/client in the canarist rootManifest I'm not sure why we did in the first place, but for now we want to pin @apollo/client in the regular dependencies to 3.4.17 because of: h... — committed to xing/hops by ZauberNerd 2 years ago
- fix: pin @apollo/client to 3.4.17 due to SSR bug in useLazyQuery https://github.com/apollographql/apollo-client/issues/9108 — committed to xing/hops by ZauberNerd 2 years ago
- chore: do not pin @apollo/client in the canarist rootManifest I'm not sure why we did in the first place, but for now we want to pin @apollo/client in the regular dependencies to 3.4.17 because of: h... — committed to xing/hops by ZauberNerd 2 years ago
- fix: pin @apollo/client to 3.4.17 due to SSR bug in useLazyQuery https://github.com/apollographql/apollo-client/issues/9108 — committed to xing/hops by ZauberNerd 2 years ago
I met this issue recently. However, it seems adding
ssr: false
in the options ofuseLazyQuery
would mitigate this issue. Like:const [doQuery, { data }] = useLazyQuery(GQL_DOC, { ssr: false });
This is odd, since useLazyQuery should be skipped in SSR by nature. Could anyone check this?
Edit: v3.5.7 just released hours ago, and the situation still the same.
Edit2: I just found
src/react/ssr/__tests__/useLazyQuery.test.tsx
and this issue can be reproduced in test environment:Edit 3: Checked v3.5.8, v3.6.0-beta.5, and main (43883b33e): all of them have the same behavior mentioned above.
We are also experiencing the same issues using the
useLazyQuery
on our SSR pages.When on Netlify, the SSR fails that uses
useLazyQuery
and would returnerror decoding lambda response: invalid status code returned from lambda: 0
.Downgrading to
v3.4.17
seems to fix the issue.I have a PR that should solve this issue, but there is a possible workaround by setting
ssr: false
in the query optionsI can confirm I am encountering the same bug: I had one place in the code where I was using
useLazyQuery
and the SSR would never complete, but when I commented out theuseLazyQuery
call it started working. This started happening after I upgraded from version 3.4.16 to 3.5.2. I’m rendering a React app on the server using Vite with frandiox/vite-ssr.The same bug occurs on version Apollo Client version 3.5.5.
I can confirm the same issue When there’s a
useLazyQuery
on page, it hangs during SSR. All 3.5 versions affected up to 3.5.6. Returning to 3.4.17 makes it work again.Same for me.
v3.4.17 everything works v3.5.0 useLazyQuery has issues with our SSR pages.
I am also experiencing the same issues using the
useLazyQuery
on our SSR pages.v3.4.8
works well.@hwillson I created a separate branch demonstrating the bug in my original repo here:
https://github.com/simplecommerce/meteor-graphql-app/tree/bug-usequery-fetchpolicy-standby
Make sure meteor is installed and execute meteor npm install and meteor run. It will run on port 3000.
The page won’t load.
If you go in this file:
/imports/ui/Info.jsx
and uncomment thefetchPolicy
, it will load fine.Not gonna lie, I love reproductions that use Meteor. 🎉 We’ll take a look - thanks!
@atarek12 @byronlanehill I just tried 3.6.6 (latest) on my repo and it seems to work fine, so whatever problem I had with the prior release 3.5.4 (i hadn’t checked for a while) is gone on my end, it could be another issue but still be related to this one I assume.