useQuery randomly not returning data and stuck in loading

[vsaarinen]

Describe the bug
After upgrading to react-query 3.5.11 from 2.26.4 last week, our project's Cypress tests started failing randomly because the app started showing a loading spinner at random times. After a lot of head-banging, we finally tracked down the issue: even though, based on the network inspector, the request had gone through successfully, react-query's useQuery was returning an object with isLoading as true and data as undefined. Reverting back to react-query 2 fixed the problems.

Most of the requests in our Cypress tests are stubbed using cy.server and cy.route. This probably shouldn't affect react-query but mentioning it here just in case.

Our cache is configured in the following manner at the top of one of our source files, so this shouldn't be caused by us accidentally creating multiple caches:

const queryCache = new QueryCache({
  defaultConfig: {
    queries: {
      staleTime: 10 * 60 * 1000,
      cacheTime: 15 * 60 * 1000,
      retry: (
        _failureCount,
        error: any,
      ) => error.status !== 403 && error.status !== 401,
    },
  },
});

// Further down:

class AppProvider extends Component<{}, State> {
  public render() {
    return (
      <ReactQueryCacheProvider queryCache={queryCache}>
        {/* ... */}
      </ReactQueryCacheProvider>
    );
  }
}

To Reproduce
Unfortunately, this happens randomly and is thus very hard to reproduce. The randomness does point towards some type of race condition. Our app performs many (~10) requests on startup.

Even though which tests fail is random, I can consistently get at least one test to fail. Is there something I can do to help track down what could be the issue?

Expected behavior
useQuery should return the data it receives in the response once the request is successful.

Desktop (please complete the following information):

• OS: MacOS
• Browser: Chrome
• Version: 87

Additional context
Happens on both Cypress version 5.3.0 and 6.2.1.

[TkDodo]

this looks surprisingly similar to #1653

[boschni]

Don't know how the tests are written but it might be good to check if they do not implicitly depend on certain timings. Are you able to reproduce it manually? This might be useful: https://docs.cypress.io/guides/core-concepts/retry-ability.html

[vsaarinen]

Don't know how the tests are written but it might be good to check if they do not implicitly depend on certain timings. Are you able to reproduce it manually? This might be useful: https://docs.cypress.io/guides/core-concepts/retry-ability.html

I haven't noticed this problem when using the app manually, so there's always a chance that this is somehow caused by Cypress. But a few reasons why I think this may be an issue with react-query:

• The error (loading spinner) occurs on app startup, before any interaction from Cypress. So it shouldn't be due to timing of commands/assertions.
• The problem goes away when react-query is downgraded to an old version.
• When inspecting the app, the network requests show that the response was received by the app but the related useQuery call returns undefined for data.

I'll see if I can narrow down the react-query version where this started happening.

[antonversal]

I can confirm the same behavior after migrating from 2.23.1 to 3.5.16.
isLoading is randomly returning true for queries with staleTime option. Everything works without staleTime.

[boschni]

Would be great if you guys could to provide a sandbox or something similar which we can use to debug the issue.

[antonversal]

Would be great if you guys could to provide a sandbox or something similar which we can use to debug the issue.

I've tried to reproduce in a sandbox without any luck (

[josewhitetower]

Commenting just to subscribe to the thread because I'm having the same issue and can't reproduce it on a sandbox. Happens on v2.26.3 and after updating to v3.6.0.

[TkDodo]

Can we try to narrow it down collectively? So far, we've seen that:

• it apparently still works on 2.23.1 according to @antonversal
• it's no longer working on 2.26.3 according to @josewhitetower

could you further narrow it down to a specific version between those two?

staleTime seems to be involved, but how do you set staleTime? via the default-config on the global cache like @vsaarinen has shown in the opening post (similar to what @fTrestour has posted in #1653), or are you setting the staleTime on the useQuery call directly?

[TkDodo]

I'm also seeing that both the opening post in this issue as well as in #1653 have the retry option set - could we rule that one out as well?

[antonversal]

@TkDodo I set staleTime in useQuery. No global settings and retry.

[vsaarinen]

Can we try to narrow it down collectively? So far, we've seen that:

• it apparently still works on 2.23.1 according to @antonversal
• it's no longer working on 2.26.3 according to @josewhitetower

could you further narrow it down to a specific version between those two?

For me, things work fine on 2.26.4. I'll try to find which version of 3 causes things to start breaking again.

[vsaarinen]

Started seeing the same issues after upgrading to 3.2.0 from 2.26.4. So it appears to be a regression introduced in version 3.

[adeelibr]

Started seeing the same issues after upgrading to 3.2.0 from 2.26.4. So it appears to be a regression introduced in version 3.

I have the same issue

[fermmm]

I finally found the cause at least for my specific case.

React-query performs a deep compare to update the component, so if your request returns the same data than in the previous request, react query will not update your component. This was happening randomly to me because the response of my request contains random changes but sometimes returns the same data. In my case I expect a re-render always.
The solution in case you have the same problem is to disable deep compare by setting structuralSharing to false like this:

export const queryClient = new QueryClient({
   defaultOptions: {
      queries: {
         staleTime: Infinity,
         structuralSharing: false
      }
   }
});

This is a bug or at least confusing because it's an "anti-pattern" since react does not expose anything that works with deep compare like this. React is based on reference equality only.

This feature was introduced recently:
#430