apollo-client: Next.js + 3.4 useQuery stuck on Loading

In Apollo Client 3.4.3 our useQuery hook stopped working correctly. On page load, useQuery will be stuck on loading: true. Refreshing the page will then let useQuery resolve correctly.

Reverting to 3.3 fixed the issue.

 "@apollo/client": "^3.4.3",
"next": "11.0.1",
  const { loading, error } = useQuery<CartQueryProps>(CART_QUERY, {
    onCompleted: (data) => {
      console.info("completed CART_QUERY", {
        data,
        loading,
        error,
      });
    },
    onError: (error) => {
      console.error(error);
    },
  });
  
  console.log({data, loading, error})

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 12
  • Comments: 25 (12 by maintainers)

Most upvoted comments

I can confirm what @Woong25 is saying. Having the option ssrForceFetchDelay set causes infinite loading. I’m not sure why i ever set this to begin with as I dont have the associated ssrMode setting! (probably some regression from next.js 9 and apollo 2.x YEARs ago) once I remove it everything works splendidly

I know a reproduction demo would be nice to have but since I’m not using any of the SSR options myself removing ssrForceFetchDelay was the fix. However this wasn’t an issue before 3.4. I believe at one point in the past I actually tried to use SSR with apollo but that was back in NextJS 9.1 and Apollo 2.x and even before hooks blewup in react. Since then I removed all SSR options from apollo itself

@brainkim #5918 looks similar yes, but as I told my team when they pointed that out #5918 is a whole pandemic ago. This just started appearing recently. Probably/definitely related though

Hello, we’re also experiencing the exact same symptoms in the Keystone project. We leverage both Next.js and Apollo, and have pinned to @apollo/client@3.3.21 temporarily to workaround this.

Would appreciate any additional insight into why this might be happening 🙏 Here’s a minimal viable reproduction of the bug we’re seeing in our project.

https://github.com/gwyneplaine/keystone-apollo-bug-repro

@gwyneplaine The keystone reproduction is fixed in 3.4.5.

@gvocale Can you check 3.4.5 and see if you’re still seeing a problem?

3.4.5 fixed the issue for me as well. Thank you!

@brainkim I can confirm 3.4.5 still has the issue. Even 3.5.0-beta.4 still has it. Only going back to 3.4.0 solved the issue for me.

@alanionita I think you have a different issue. The issue encountered here is that the client never made a request to the server.

Still seeing this issue on 3.4.7

We’re running two queries right after each other and the second query always appears to be loading.

The server is resolving the query so it seems to be an issue with the client lib

  const searchForStuff = useQuery(STUFF_QUERY);
  const findSomethingElse = useQuery(SOMETHINGELSE_QUERY);

Not using ssrForceFetchDelay

Pretty simple ApolloClient setup

const client = new ApolloClient({
  link: authLink.concat(httpLink),
  cache: new InMemoryCache(),
});

@brainkim You probably know this already but ssrForceFetchDelay explanation can be found here https://www.apollographql.com/docs/react/performance/server-side-rendering/#overriding-fetch-policies-during-initialization (I read a few posts above when you mentioned you wasn’t sure what it was for)

In my initial tests, without ssrForceFetchDelay, I could see queries being executed in my network log in dev console on initial load, which shouldn’t happen since I am using SSR and they are already fetched from the server. Adding this option prevents that.

In my previous post above, in case it helps, when I tested 3.4.3 I added a console log for the variables that changed in the if condition and I noticed that this.client.disableNetworkFetches always returned true but when I console.log this.client I could see it being set to false, which is why I pointed to the ApolloClient line, I think its related maybe, hope it helps.

Sorry if I am not clear.

I have a weird issue too mentioned here https://community.apollographql.com/t/cache-evict-and-usequery-ssr/1006 and I think it might be related to this, my login/logout code would no longer re-render after I used client.resetStore and some queries no longer refetch when I run cache.evict (those generated via SSR).

Same as the people here, I can definitely pinpoint that it works up until 3.4.3, if I stay on 3.4.2 everything works fine.

UPDATE

Seems to be related to this change for me.

https://github.com/apollographql/apollo-client/commit/b413b93c6e81ab7f66babab1f018c710d5dbf166#diff-35bb2db9b3f254947ad9d5c0fc024f5f09e709e22557f8a7369025df007870c7

I think its because of this: https://github.com/apollographql/apollo-client/blob/b0da267d24d8713987e9ff8d2240c5c7ed94eb94/src/core/ApolloClient.ts#L188

Same issue here for 3.4.7 except I am using UmiJS. All my queries just continually load. If I turn off ssrMode, everything seems to work. I was able to revert back to 3.4.2 for now.

I am experiencing the same issue, but with useLazyQuery, this not only is stuck on loading, but it looks as if the query is never really performed, as I can not see anything in the developer console of CHrome

Had the same issue, only way to fix was to revert back to 3.3. Very confusing at first as no errors were thrown and requests would just hang forever.

😠 Okay let me do some comparing of 3.3 and 3.4 and see if I can get this old behavior for y’all 😄

is a whole pandemic ago

👴 👴 👴 👴 👴 👴

I am having exactly the same issue. When I use client object directly I got an answer, but when I try to use useQuery, it stuck at loading. Using Next, and 3.4.7 for apollo client. This issue should be re-opened @brainkim

@brainkim Infinite loading with ‘ssrForceFetchDelay’ option in apollo settings. Can anyone check this issue?

I used version 3.4.7

"@apollo/client": "^3.4.7",
export const client = new ApolloClient({
    ssrMode: typeof window === 'undefined',
    ssrForceFetchDelay: 100, // Infinite loading with this option
});

@brainkim Deleting the whole folder of node_modules and yarn.lock file and reinstalling from scratch got the issue fixed for now. Thanks for your time.

@gvocale I’m sorry to hear this! Looking into this right now.