Null doesn't propagate up to data if query result type is non-null itself

[pksieminski]

What happened?

When a resolver of non-null field returns a null, it is propagated up to the query result type properly, but if query result type is non-null itself, it does not propagate up to data field.

Below there are two scenarios where it behaves wrong with a list and relay style object response types.

{
  "errors": [
    {
      "message": "error message",
      "path": [
        "customersList",
        0,
        "email"
      ],
    },
    {
      "message": "error message",
      "path": [
        "customers",
        "edges",
        0,
        "node",
        "email"
      ],
    }
  ],
  "data": {
    "customersList": null,
    "customers": null
  }
}

What did you expect?

According to this spec:

If a List type wraps a Non-Null type, and one of the elements of that list resolves to null, then the entire list must resolve to null. If the List type is also wrapped in a Non-Null, the field error continues to propagate upwards.

If all fields from the root of the request to the source of the field error return Non-Null types, then the "data" entry in the response should be null.

I would expect following result in both cases of list and object non-null response types:

{
  "errors": [
    {
      "message": "error message",
      "path": [
        "customersList",
        0,
        "email"
      ],
    },
    {
      "message": "error message",
      "path": [
        "customers",
        "edges",
        0,
        "node",
        "email"
      ],
    }
  ],
  "data": null
}

Minimal graphql.schema and models to reproduce

type Customer {
  id: ID!
  email: String!
}

extend type Query {
  customersList: [Customer!]!
}

versions

• v0.17.25-0.20230131161909-cf1607ad8fe
• go1.19

Looks like there was similar issue which supposedly is fixed, but maybe it is back or didn't propagate up to data: #1230

[vikstrous2]

same issue discussed here #2523

[StevenACoffman]

Thanks for reporting this, and sorry for the problem. This appears to have been fixed in #2577