3.0.0-beta.43 Missing cache result fields warning, cache not updated after mutation

I’m getting the following error after upgrading to 3.0 beta.43

Look like related to #5603 and #5146. Do i need to write keyFields manually for all type?

const link: any = errorLink.concat(authLink.concat(httpLink as any));
export const apollo = new ApolloClient({
  link,
  cache: new InMemoryCache(),
});

export default function ProductLayout() {
  const query = useProductLayoutQuery({ variables: { productId  } });
  const product = query.data?.product;

  return (
    <Page>
         <Product />
    </Page>
  );
}

// ProductLayout.gql
 
query productLayout($productId: Int!) {
  product(id: $productId) {
      id
      name
      description
  }
}

export default function Product() {
  const query = useProductQuery({ variables: { productId } });
  const product = query.data?.product;

  return <div />
}

// Product.gql
query product($productId: Int!) {
  product(id: $productId) {
    id
    fullname
  }
}

Intended outcome:

The cache should up to date Actual outcome:

The cache is not updated How to reproduce the issue:

Versions 3.0 beta.43

[macrozone]

Looking at the first MissingFieldError for example, we see Can't find field 'name' on object .... This means at some point you ran a query to retrieve and store the data mentioned in that error message, and included a name field in your query’s selection set. Then at some other point in your application, you ran a very similar query that ended up resolving to the same entity stored in the cache, but you didn’t use the name field in your selection set. This means the name data ended up being dropped from the cache, so the first query that was dependent on it can no longer find it.

I don’t quite get this. The docs state clearly (https://www.apollographql.com/docs/react/caching/cache-field-behavior/#merging-non-normalized-objects) that as long as we fetch the id, the two objects can safely be merged in cache.

I am asking this, because i get tons of “Missing cache result fields” warnings, despite in my opinion, all these entities could have been merged safely. Do i need to customize InMemoryCache to fix this?

edit: and just to clarify:

if i have a list and a detail view and in the list i fetch just the id and the name of a product, but in the detail page i fetch id, name, description and so on.

Should i get this warning in this case, yes or no? i tried to debug it on my project and it seems like this is indeed the case. I get the impression that this is a total normal pattern to fetch once less data and later more data from an entity and should not trigger a warning or am i wrong?

[hwillson]

As mentioned in https://github.com/apollographql/apollo-client/issues/6136#issuecomment-615933193, this new warning is intentional. When query/cache mismatches like this happen in AC2, they are essentially swallowed. For example, when you have one query that’s relying on a certain set of data in the cache, but run another query that ends up removing some of the fields the first query was expecting from the cache, the inability of the first query to pull out what it needs is not exposed to developers. This cache underwriting/overwriting problem has been a longstanding issue in the past, so AC3 introduced this new warning to help developers know when this problem occurs.

Looking at the first MissingFieldError for example, we see Can't find field 'name' on object .... This means at some point you ran a query to retrieve and store the data mentioned in that error message, and included a name field in your query’s selection set. Then at some other point in your application, you ran a very similar query that ended up resolving to the same entity stored in the cache, but you didn’t use the name field in your selection set. This means the name data ended up being dropped from the cache, so the first query that was dependent on it can no longer find it. Depending on your fetch policy this might not be an issue at all, which is why this is a development time warning only (it won’t show in production). But it’s also quite possible you didn’t mean to do this. To resolve this cache mismatch issue (and again depending on your fetch policy), Apollo Client might decide to head to the network to fetch the data it needs, including the missing name field. But this means an extra network hit, which could have been avoided, if you just included the extra name field in both queries (since again, they’re set to point to the same entity in the cache).

If you’re migrating from AC2, you can definitely choose to ignore these errors if you want to, but we highly recommend looking into their cause. Addressing them will help keep your cache healthy and improve cache hits.