watchQuery over-fetching

Intended outcome:

When having active watchQuery in one component and triggering another watchQuery deeper in the component tree only the one deeper in the tree should create a new network request.

The 1st query should not be triggered together with the 2nd query. If any field shared between the two queries changes with the response of 2nd query, the 1st watchQuery should update due to cache changes anyway.

Example

1st query

query {
  file(id: 1000) {
    id
    name
    size
  }
}

2nd query

query {
  file(id: 1000) {
    id
    name
    mimetype
  }
}

Actual outcome:

When the 2nd query is executed, the 1st query is sending a new network request again effectively over-fetching.

How to reproduce the issue:

Reproduction: https://stackblitz.com/edit/simple-apollo-angular-example-maz5cx Keep refreshing with the stackblitz refresh button and more often than not (gif below).

Versions

  System:
    OS: macOS 10.15.7
  Binaries:
    Node: 12.18.2 - ~/.nvm/versions/node/v12.18.2/bin/node
    Yarn: 1.22.5 - ~/Projects/censhare-hub/node_modules/.bin/yarn
    npm: 6.14.6 - ~/.nvm/versions/node/v12.18.2/bin/npm
  Browsers:
    Chrome: 85.0.4183.121
    Edge: 85.0.564.68
    Firefox: 81.0
    Safari: 14.0
  npmPackages:
    @apollo/client: ^3.0.0 => 3.2.2 
    @apollo/link-persisted-queries: ^1.0.0-beta.0 => 1.0.0-beta.0 
    apollo: ^2.30.3 => 2.31.0 
    apollo-angular: ^2.0.4 => 2.0.4 

[klemenoslaj]

In the first case, since one query requests fewer fields for each post than the other query, the other query will find the post objects from the justIds query insufficient for its purposes

Shouldn’t it be the other way around?

allPosts is the query with all the fieds. justIds is query with ids only.

allPosts query is fired first, it get’s all the ids and the rest of the properties. Somewhere around that time app-test is rendered which causes justIds query to fire.

I would expect this to be the end. However for some reason the 3rd request is made with the allPosts query.

What you’re saying is this (if I got it right, otherwise sorry 😇 ):

justIds is fired - no data in cache - request made allPosts is fired - no sufficient data in cache - request made

What I am saying is this:

allPosts is fired - no data in cache - request made justIds is fired - data is in cache, but cache-and-network policy is configured - request made allPosts is fired again - I expect this should not have happened

What I don’t understand is why the allPosts get’s fired again? There is absolutely no need for it, is it? The justIds query is asking for subset of data, but it only goes trough the network because of cache-and-network fetch policy.

[KeithGillette]

I believe I am encountering the same issue in our Apollo Client 3.2.2 project. In our case, we have 2 sibling components, each initiating a watchQuery on queries requesting different fields on the same object. The query document, operation name, and variables are distinct. Activating a second component starts its watchQuery, which then triggers an update on the watchQuery in the first component. That first query differs in variables from the first in using pagination for the requested field, and so is refetched with incorrect pagination since it’s triggered outside of a fetchMore call, resulting in incorrectly displayed results.