Caching not working for nested Query

Hi!

When having the following schema, caching seems not to work correctly:

{
  appearances(ids: [6, 4]) {
    items {
      id
      name
    }
  }
}

Intended outcome
When I do the upper query I expect that a second query with only a subset of variables (ids: [6]) would be fetched from the cache.

Actual outcome
However this is not the case. Instead the whole query is fetching over the network again.

How to reproduce the issue
I made two queries:

const query1 = gql`
  query q1 {
    appearances(ids: [6, 4]) {
      items {
        id
        name
      }
    }
  }
`;

const query2 = gql`
  query q2 {
    appearances(ids: [6]) {
      items {
        id
        name
      }
    }
  }
`;

In my case, I use react-apollo with the query component, but the same can be achieved with plain javascript and apollo compose. Mind the fetchPolicy="cache-only" to verify that it is fetched from the cache.

<Query query={query1}>
  {({ loading, error, data }) => {
    if (error) {
      return 'Error!';
    }
    
    if (loading) {
      return 'waiting...';
    }

    return (
      <Query query={query2} fetchPolicy="cache-only">
        {({ loading: loading2, error: error2, data: data2 }) => {
          if (error2) {
            return 'Error!';
          }
          
          if (loading2) {
            return 'waiting again...';
          }

          /* --- data2 is always empty --- */
          console.log(data, data2);

          return 'done!';
        }}
      </Query>
    );
  }}
</Query>

The issue here seems to be the items nesting, because if I omit it from the schema the caching works. But isn’t this nesting common practice with stuff like edges in GraphQl in order to have another field with resultInfo?

Versions apollo-client 2.3.7 react-apollo 2.1.9

[SilvanCodes]

From my understanding, I can identify two problems with your approach/expectation.

1. Problem: Apollo identifies cached queries by a combination of their name and their variables. So your two queries with arguments ids: [6, 4] and ids: [6] seem unrelated to Apollo. Generally this problem could be addressed by using the @connection directive, but that doesn’t solve your issue.

2. Problem: As you are not directly querying the item and passing it the id like

item(id: 6) {
  id
  name
}

Apollo can’t know that the arguments you are passing to appearances are meant to be ids of items. Therefore it can’t look them up in the cache. The first point in time where it can know, is when the data is returned from your server and it sees the id field on your items. It might appeal that the cache redirects offered by Apollo might come to rescue, but I suspect that you’ll run into the same issue I have. Apollo doesn’t yet support chaining or nesting resolvers by types, like queries are resolved on the server-side.

My last assumption might be wrong, but your issue is not trivial still. I hope I clarified it’s not just a bug in the caching mechanic and even thought your described behavior might be desirable it has to be accounted for with custom logic.

[7yp0]

But I don’t want to have local state with the @client notation. The reason why I have set fetchPolicy to cache-only was to demonstrate that the query result does not show up in the cache.

What I really want to achieve is, that

appearances(ids: [6]) {
      items {
        id
        name
      }
    }

get’s fetched from the cache instead from the server, if the same query has been done before but with different variables (ids: [6, 4]). I have also tried to do something with cacheRedirects but without any success so far.

It would be nice if this issue could be fixed, or maybe I’m missing a configuration for a nested query like this? As mentioned above: This seems like a pretty common case with edges which are used a lot in graphQl in my understanding