Behavior change: In v3.5+, minimal useQuery example briefly returns old data after variables changed

[bengotow]

Intended outcome:
Prior to Apollo Client 3.5, changes to the variables provided to a useQuery hook were immediately reflected in the hook's returned data (within the same render).

Actual outcome:
Starting with Apollo Client 3.5, the useQuery hook returns data for old variables for at least one render after new variables are provided, rather than returning cached data / empty data / a loading state that reflects the new variables.

This is a serious regression and it seems that it can't be easily detected. If you inspect the return value of the hook in the render when variables are changed:

  const { loading, error, variables, data } = useQuery(FRUIT_FAMILY_QUERY, { variables: { family }})

// loading is false
// error is false
// variables contains the NEW `family` value
// data contains the OLD query results for a different family

How to reproduce the issue:
I've created a super small reproduction case with CRA + Typescript here:
https://github.com/bengotow/apollo-client-issues/blob/new-variables-old-data/src/AppNewVariablesOldDataBug.tsx

To trigger the bug, click Switch Fruit Family to set a new variable value. The app crashes at an assertion check.

Findings:

• If you change back to an earlier version of Apollo Client (my team was using 3.3.16), the useQuery's result reflects the new variables immediately and the app does not crash.

• I've turned off caching entirely (using new InMemoryCache({resultCaching: false})) to make sure those settings weren't the cause.

Versions

    OS: macOS 12.1
  Binaries:
    Node: 16.13.0 - ~/.nvm/versions/node/v16.13.0/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 8.1.0 - ~/.nvm/versions/node/v16.13.0/bin/npm
  Browsers:
    Chrome: 97.0.4692.71
    Edge: 97.0.1072.62
    Firefox: 95.0.2
    Safari: 15.2
  npmPackages:
    @apollo/client: 3.5.7 => 3.5.7 

[whytspace]

I just stumbled upon this problem on our production system today. It seems that for 1 render, the variables passed in are new, the data returned is still old, while loading is also false.
On the next render, data is undefined, as expected, while the query starts to load.

I do have a loading state in my app, but how can I know that the returned data is outdated, when loading is still false and variables returned from the query are also already updated.

This is causing me some problems, since I rely on data being in sync with the other return values.

The only way for me to check if the data is correct, was actually to compare the input variables with the returned data. This is not ideal, since not every graphql query returns all it's varaibles.

@bengotow Did you find a (at least temporary) solution to the problem?

@benjamn Is this an intentional change? If so, how do I determine whether data is already updated or not?

[dmarkow]

@whytspace Same issue, the added loading: false render makes it impossible to tell if we have the new data or not, and since we redirect based on the updated search results, it was causing redirects to the wrong pages. Our temporary solution was to lock to 3.4.17

[clairestolp]

This looks a lot like the issue I am having as well. #9340

I can confirm that rolling back our Apollo Client from v3.5.8 to v3.4.17 has fixed the issue.

[whather]

This is a huge regression for us as well. I would expect the loading flag to at least be set to true after changing variables, but instead you get the old data returned for the new variables and the app blows up down the stack because of it.

[dmarkow]

This seems to be fixed with the new 3.6.0 release. The render immediate following a variable change now has loading: false and no old data.

[dylanwulf]

Yes this was fixed by #9599 which should be available in v3.6.0

[bignimbus]

Hi all, I'm closing this issue as resolved due to the above. Please do reach out if you need more support here 🙏🏻