Make ObservableQuery#getCurrentResult always call queryInfo.getDiff()

[benjamn]

Appears to fix #7978, by always giving the cache a chance to provide an up-to-date result for the given options, rather than relying on observableQuery.lastResult, which may be stale.

Note that QueryInfo#getDiff knows how to handle fetchPolicy: "no-cache", so it's safe to call even in that case.

[dylanwulf]

@benjamn Thanks! This does appear to resolve the previous data issue. I do have a question about the network-only fetch policy though. If I have a query that uses network-only, and I change the variables while the query is still mounted, are the results for the new variables supposed to be obtained from the cache? When I change the variables in my reproduction, it appears to (1) get results from the cache to display immediately, (2) fetch fresh data from the server, then (3) display the new data from the server. This behavior sounds more like cache-and-network to me, but maybe I'm misunderstanding something?

[dylanwulf]

I'm also a little confused about how nextFetchPolicy is supposed to behave when changing variables. It seems to me like changing variables should reset back to fetchPolicy instead of using nextFetchPolicy. Our app has a paginated (infinitely scrolling) query with fetchPolicy: 'network-only', nextFetchPolicy: 'cache-first'. The nextFetchPolicy: 'cache-first' is necessary for pagination to work correctly, but every time any of the variables change we want to discard the cached results and fetch fresh data from the server. I couldn't find an easy way to accomplish that with the current API, but again I might just be misunderstanding something.

Anyways, thanks again! ❤️

EDIT: This behavior with nextFetchPolicy doesn't seem to be occurring in v3.3. It looks like something in the v3.4 branch made it so that changing the variables on a query will use nextFetchPolicy instead of fetchPolicy. I can create a separate issue/reproduction for that if you want?

[benjamn]

@dylanwulf A separate issue/test/repro would be great, if possible!

Alternatively, you could try out different beta/rc releases to figure out where the change happened. The first beta was @apollo/client@3.4.0-beta.0, continuing until @apollo/client@3.4.0-beta.28, and then @apollo/client@3.4.0-rc.0 through @apollo/client@3.4.0-rc.14 (so far). I don't know if git bisect will be much use, but a manual binary search should take 6ish steps.

[dylanwulf]

@benjamn Ok I submitted a new issue with reproduction in #8426. Looks like it first showed up in rc.5. I'm still wondering if you could answer my question about expected behavior of the network-only fetch policy in my first comment? That behavior is separate from the issue I found in v3.4 and I can't tell if it's intentional or not.

[brainkim]

LGTM. Some of the logic changes might be blocking what I was currently working on.