ID returned but apollo not merging cache results for nested objects

[JasonMan34]

Intended outcome:
Have the cache merge nested objects when an ID is returned

Actual outcome:
The cache result is overwritten by the latest query even though an ID is returned

How to reproduce the issue:
Repro: https://codesandbox.io/s/unruffled-faraday-uq8ch
On the first render both PEOPLE_1 and PEOPLE_2 queries will be called, and once PEOPLE_2 gets a response the console will show this warning message:

Cache data may be lost when replacing the city field of a Person object.

To address this problem (which is not a bug in Apollo Client), either ensure all objects of type City have IDs, or define a custom merge function for the Person.city field, so InMemoryCache can safely merge these objects:

However, all objects of type City have IDs.
Changing the cityId field's name to id resolves this issue, but that's not an option for me since our database isn't build like that

Versions

System:
OS: Windows 10 10.0.18362
Binaries:
Node: 12.16.1 - C:\Program Files\nodejs\node.EXE
npm: 6.13.4 - C:\Program Files\nodejs\npm.CMD
Browsers:
Chrome: 86.0.4240.75
Edge: Spartan (44.18362.449.0)
npmPackages:
@apollo/client: ^3.2.0 => 3.2.0
apollo-link-error: ^1.1.13 => 1.1.13

[benjamn]

@JasonMan34 Thanks for the reproduction!

Here's how you tell InMemoryCache the primary key field for City objects is something other than id:

new InMemoryCache({
  typePolicies: {
    City: {
      keyFields: ["cityId"],
    },
  },
})

[JasonMan34]

Is there any way to tell apollo to assume a singular keyField using the field with type ID?
Our API has dozens of different types, none of them have an 'id' field, but they are properly identified in the schema with the ID type. Applying typePolicies for all of them would be rather sisyphean, especially since types are being added quite frequently at this stage

[benjamn]

There's nothing about the ID type in GraphQL that guarantees it's the primary key of the object that holds it, so I don't think that short-cut will work. However, you might be able to use type policy inheritance to reuse a common keyFields configuration between multiple types that inherit from the same supertype: #7065

[JasonMan34]

Unfortunately that won't work for us. Either way, thank you for the help and clarifications!