Apollo Client has null values filtered in queries since v3.9.0 when using a type policy

[bengry]

Issue Description

We have a type policy for handling Relay-like connection fields which broke in Apollo 3.9.0. Works fine in previous versions. See the attached repro for more information, and the behavior in ~3.8.0 vs >= v3.9.0.

The difference is that in v3.9.0 onwards, when we get nodes: null back from the server, this key gets removed after going through our type policy.

This breaks some of the stuff we rely on, since we look at the shape of the response in some hooks, which checks if nodes exists on data, which it doesn't in >= v3.9.0.

This happens for example in this scenario (see the CSB link to see it live):

For a query that contains a nullable field, such as this:

extend type Query {
  dogs(after: String, first: Int): DogConnection!
}

type DogConnection {
  edges: [DogEdge!]
  nodes: [Dog!]
  pageInfo: PageInfo!
  totalCount: Int!
}

type PageInfo {
  totalCount: Int!
  hasNextPage: Boolean!
  endCursor: String
}

type DogEdge {
  node: Dog!
  cursor: String!
}

type Dog {
  id: ID!
  name: String!
  ...
}

If the backend returns:

{
    "data": {
        "dogs": {
            "nodes": null,
            "pageInfo": {
                "hasNextPage": false,
                "endCursor": null,
                "__typename": "PageInfo"
            },
            "totalCount": 0,
            "__typename": "DogConnection"
        }
    }
}

for the following code:

function MyComponent() {
  const { data } = useDogsQuery({ ... });
}

gql`
	query Dogs($first: Int!, $after: String!) {
	  dogs(first: $first, after: $after) {
	    nodes {
	      id
	    }
	    pageInfo {
          hasNextPage
	      cursor
	    }
	    totalCount
	  }
	}

in Apollo Client 3.8.x, data is:

const data = {
    "nodes": null, // ❗ Notice that `nodes` is kept in the object, just as `null`
    "pageInfo": {
        "hasNextPage": false,
        "endCursor": null,
        "__typename": "PageInfo"
    },
    "totalCount": 0,
    "__typename": "DogConnection"
}

While in 3.9.x, data is:

const data = {
    // ❗ Notice that the `nodes` key is removed from the object entirely
    "pageInfo": {
        "hasNextPage": false,
        "endCursor": null,
        "__typename": "PageInfo"
    },
    "totalCount": 0,
    "__typename": "DogConnection"
}

Link to Reproduction

https://codesandbox.io/p/devbox/peaceful-chihiro-p75rds

Reproduction Steps

No response

@apollo/client version

3.9.0

[alessbell]

Hi @bengry 👋 Thanks for providing the reproduction - unfortunately I'm not able to access it:

Would you mind checking that it's shared publicly (assuming that was your intent)? Thanks!

[bengry]

Hi @bengry 👋 Thanks for providing the reproduction - unfortunately I'm not able to access it:

Would you mind checking that it's shared publicly (assuming that was your intent)? Thanks!

Woops, try again now please

[alessbell]

@bengry yes, I can view it now. I'll need to dig into this a bit more and I'm nearing the end of my day, but will take a look as soon as I can. Thanks!

[varbrad]

Just adding a comment here to say we're experiencing the same issue, it appears our defined typePolicies are being ignored and certain types we do not wish to normalise are being erroneously included in the cache, which then breaks several things across our tests and application, and leads to the same behaviour as seen above.

For example, we have a query that returns something similar to the below;

query TermsAndConditions {
  xyz {
    hasSignedTerms
  }
}

Where xyz: XYZ and type XYZ { hasSignedTerms: Boolean! }

Unfortunately the xyz type (obfuscated here) has no identifying label/id we can use, so we employ a strategy whereby it's type is given a keyFields: false value.

In 3.8 this would always mean the data property would return { __typename: 'XYZ', hasSignedTerms: true/false } whereas within 3.9 we are seeing frequent returns of { __typename: 'XYZ' } with the hasSignedTerms property being omitted entirely (which then breaks things as our TS types assume it always exists, etc.).

[eltonio450]

I think the same happens with empty lists

[alessbell]

Hi all 👋 This regression is related to the bug fix in #11202. We're looking into it and should have an update soon, thanks for your patience.

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Client usage and allow us to serve you better.

[alessbell]

The fix will go out in a next patch release in the next day or two - I've tested snapshot release 0.0.0-pr-11576-20240206204955 with your sandbox @bengry and the bug no longer occurs. Thank you for reporting this issue!

[github-actions]

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.
For general questions, we recommend using StackOverflow or our discord server.