Apollo-client: Local resolvers with @client(always: true) return stale values in `useQuery`

[azundo]

Intended outcome:
Trying to use apollo to manage local state. We have some types that we write to the cache and wish to include calculated fields through a local resolver. The useQuery hook accessing the result includes a @client(always: true) directive and so if the query is refreshed it is expected to get the new calculated value for that field.

Actual outcome:
The useQuery result only ever sees the initial value of the local resolver field despite being marked as @client(always: true) in the query.

How to reproduce the issue:
See tests here - the watchQuery test passes and works as expected while the useQuery test does not:
https://github.com/azundo/apollo-client/pull/1/commits/51286527c623dd0d9e8a88d43dbef21c9302630e

Versions
Tested on master branch
System:
OS: macOS Mojave 10.14.6
Binaries:
Node: 12.3.0 - ~/.nvm/versions/node/v12.3.0/bin/node
Yarn: 1.22.4 - /usr/local/bin/yarn
npm: 6.9.0 - ~/.nvm/versions/node/v12.3.0/bin/npm
Browsers:
Chrome: 83.0.4103.116
Firefox: 72.0.2
Safari: 13.1.1

[azundo]

This issue can be tracked down to line 511 in core/ObservableQuery.ts where forced local resolvers are not run against the cache diff from the queryManager. Thus the initial cached value of the local resolver remains and always overwrites the updated value on line 166 of core/ObservableQuery.ts in getCurrentResult().

// in `getCurrentQueryResult` in `ObservableQuery`
    const { result, complete } = this.queryManager.cache.diff<TData>({
      query: this.options.query,
      variables: this.variables,
      previousResult: this.lastResult?.data,
      returnPartialData: true,
      optimistic,
    });

Compare the above to resultsFromCache in core/QueryManager where the cache diff is augmented by the forced resolvers as expected.

[benjamn]

@azundo Can you put those tests into a PR?

[azundo]

@benjamn https://github.com/apollographql/apollo-client/pull/6553

[azundo]

@benjamn thanks for the quick fix and release! I upgraded to rc.11 and can confirm it fixed the issue in our app code that motivated this.