Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
pnispel opened this issue Jan 23, 2023 · 2 comments

Comments

@pnispel
Copy link

pnispel commented Jan 23, 2023

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
Copy link
Contributor

This is the default getDataID function. So by changing it like you did is the correct way.

function defaultGetDataID(
fieldValue: {[string]: mixed},
typeName: string,
): mixed {
if (typeName === VIEWER_TYPE) {
// $FlowFixMe[prop-missing]
return fieldValue.id == null ? VIEWER_ID : fieldValue.id;
}
// $FlowFixMe[prop-missing]
return fieldValue.id;
}

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
Copy link
Contributor

kav commented Jan 15, 2024

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',
  },

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants