Nested non-null fields mis-behaving

[bkeithlaw]

Here is an example schema and query that is raising generating unexpected errors in a small graphQl server that I've built, using gengql.

Schema (reduced to the bare essentials):

scalar Time
type Hub {
  id: ID!   # unique ID for Hub, across all hubs in any ISO
  name: String
}
type Prediction {
  hub: Hub!
  predictionTime: Time!
  latestForecastTime: Time!
  latestActual: Float!
  forecasts: [Float!]!
}
type Query {
  latestHubPrediction(hubId: ID): Prediction                  
}

And here is the query I'm sending in. Note the hubId value is intended to return a null Prediction.

query {
  latestHubPrediction(hubId: "not-there") {
    hub {
      id,
      name
    }, 
    predictionTime,
    latestForecastTime,
    latestActual
  }
}

But instead of returning

{
  "data": {
    "latestHubPrediction": null
  }
}

It's returning

{
  "errors": [
    {
      "message": "must not be null",
      "path": [
        "latestHubPrediction",
        "hub"
      ]
    },
    {
      "message": "must not be null",
      "path": [
        "latestHubPrediction",
        "predictionTime"
      ]
    },
    {
      "message": "must not be null",
      "path": [
        "latestHubPrediction",
        "latestForecastTime"
      ]
    }
  ],
  "data": {
    "latestHubPrediction": null
  }
}

The requested, non-null, sub-fields that would have been inside of the larger, nullable, return value are causing errors. I've also experimented with return a list at the top level and another object type with a nullable prediction field in it. In all cases, if the query requested a sub-field that is declared as non-null, it raises an error.

Is this correct GraphQl behavior? It seems non-intuitive to me, but I haven't found a reference that nails it down one way or the other.

Keith Law

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[frederikhors]

Nope

[rleavengood-scwx]

I saw a similar issue and in my case it was not an issue in gqlgen, but was because my database ORM layer was filling in a relation with an empty object, which was confusing for gqlgen. In fact there was only an error when some timestamp fields were accessed since gqlgen considers the "zero time" as null.

[wilhelmeek]

I don't believe there's a bug here. The behaviour described in the linked issue is consistent with the spec.

Some time has passed, so I don't believe this will be of any value, but @bkeithlaw I believe your resolver implementation may be returning an empty struct instead of nil.