-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
null ID should not be considered cacheable keys #9814
Comments
I solved this by using a typePolicy referencing the product.id, which in this case is unique for each query result. But I don't think this should be necessary. The default behaviour is counter intuitive and can easily lead to unexpected errors. |
Another approach would be to exclude the id for let's say non id scenario's. But it all seems a bit of overkill. null ids should simply not be considered cacheable keys |
@mschipperheyn Sorry to keep you waiting here, but I fully agree the default behavior should be to treat multiple objects with |
Hi all 👋🏻 I'm doing some housekeeping and noticed that this issue should have been closed by #9862. So I'm closing the loop and therefore, this issue! Let us know if you need more support here 🙏🏻 |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Intended outcome:
I have a server side response that contains an array with two different objects with null IDs. I would expect that the missing cache key would not be interpreted as an actual cache key and I would get 2 different objects on the client side.
Actual outcome:
What I'm getting is an array with 2 identical objects. A missing cache key should be considered as a "unique value".
How to reproduce the issue:
Graphql
server side query results (Note the different id)
client side query result (note the identical ID)
Versions
The text was updated successfully, but these errors were encountered: