Relay cache seems to be ignoring nodeInterfaceIdField for caching if "id" field is fetched

[pnispel]

We like to use nodeId as a cache key and id as routing/identifiers in our API.

we have the following config:

    "schemaConfig": {
      "nodeInterfaceIdField": "nodeId"
    }

nodeId here is a base64 encoded object of the table id and table name in postgres.

In a query like:

query {
  records {
    nodes {
      id
    }
  }
}

the response normalizer will log

Warning: RelayResponseNormalizer: Invalid record `9`. Expected __typename to be consistent, but the record was assigned conflicting types `Account` and `Company`. The GraphQL server likely violated the globally unique id requirement by returning the same id for different objects.

we currently get around this by doing:

new Environment({
  getDataID: (fieldValue) => fieldValue.nodeId,
})

but that isn't documented and probably breaks other things. one of note is it seems that routine updates don't reflect in the cache and have to be manually updated via updater or we have to bust the entire cache and refetch.

Things work fine if we don't fetch id, but that doesn't work because of how our mutations are laid out.

[edvinerikson]

This is the default getDataID function. So by changing it like you did is the correct way. https://github.com/facebook/relay/blob/6d013387f27bfd5cde684033c5e1bf93afeea9d2/packages/relay-runtime/store/defaultGetDataID.js#L16-L26

Regarding your other issue with mutations, it could be that something still doesn't use getDataID in the mutation APIs. But I'm not sure though.

[kav]

It seems like the default getDataID function use the noderInterfaceIdField in the schemaConfig? With that value being defaulted to id rather than hardcoded to id itself? Happy to pr this if there is agreement here.

  schemaConfig: {
    nodeInterfaceIdField: 'nodeId',
  },