What keyFields value does Apollo Client v3 InMemoryCache use for objects without id or _id?

Direct answer

When a normalized object has neither an id nor an _id field, Apollo Client v3’s InMemoryCache behaves as follows:

• If no keyFields policy is defined for the type, the cache falls back to the chain: first try id, then _id, and if both are absent it stores the object only under its parent’s path (i.e., it is not given a top‑level cache key).
• If you explicitly set keyFields: [] for that type in a typePolicy, the fallback chain is bypassed. The object is treated as unnormalized: it receives no generated cache key and is reachable only via the parent object’s field.

Confirmed facts

• The default keyFields value for a type is undefined (i.e., “not set”).
• When keyFields is undefined, the cache uses the id → _id → parent‑path fallback.
• When keyFields is defined (even as an empty array), Apollo skips the fallback and uses exactly what you provided.

Steps to verify the behavior

1. Define a simple type policy for the type in question, e.g.:

const cache = new InMemoryCache({
  typePolicies: {
    YourType: { keyFields: [] } // or omit this line to test the default
  }
});

1. Write a query that returns a nested object of that type without id or _id.
2. After the request, inspect the cache with cache.extract().
3. If keyFields is omitted, you will see the object appear as a top‑level entry only when either id or _id is present; otherwise it will be nested under its parent.
4. If keyFields: [] is set, the object will never appear as a top‑level entry; it will exist solely under the parent’s field.

Missing diagnostic detail

To be certain which path applies, confirm whether you have any typePolicy (direct or via inheritance) that defines keyFields for the type in question. If such a policy exists, its value determines the behavior; otherwise the default fallback chain is used.