Client Controlled Nullability: Null Propagation

[twof]

Spec changes
To get a better idea of where we stand, I'll add a poll so people can vote on their favorite option. This vote is non-binding, and is only one factor in choosing which syntax we land on I'll open new threads for people to discuss each option below.

I'm going to try and separate null propagation and error handling discussion. In the original thread and during working group discussions, the conflation of the two has been causing some confusion about what options exist I think. For example, we could feasibly decide on any combination of (status quo null propagation/propagation to the nearest question mark) and (caught errors marked handled/caught errors put in a separate array/caught errors include destroyed data).

! acts like Non-Nullable

Nondestructive !

Null propagates to nearest ?

Update (March 6th, 2022): Option three was selected for development at the last working group meeting.

[twof]

Option 1

! acts like Non-Nullable

Fields marked with ! are treated exactly like Non-Nullable schema fields. If null is found for one of those fields, then it propagates to the nearest Nullable parent.

Example

Schema

type Business {
  name: String
  isStarred: Boolean
}

Query

{
    business {
        name
        isStarred!
    }
}

If isStarred has a ! but returns null and business is nullable, the result will be:

{
  "data": {
    "business": null
  }
}

If business has a !, the response will be:

{
  "data": null
}

[twof]

Option 2

Nondestructive !

The required designator (!) does not change the content of data. It only exists to provide information to GraphQL clients. They can choose what to do when a field marked with ! comes back null. Client behavior is likely to differ, but this flexibility can be seen as positive or a negative. This option would only change the language and validation portions of the GraphQL spec. Fields marked with ! will have a flag attached to them to indicate that the client believes they are required.

[rivantsov]

I assume when field marked with ! returns null, there's also error object returned?

[twof]

There could be. I'm trying to separate discussions on null propagation and error handling, but I haven't got around to writing up the error handling thread yet. I'm going to try and make sure that's up a few days prior to the working group meeting.

[rivantsov]

I think it SHOULD be, since then the error is the ONLY outcome of the ! mark in the request

[twof]

This option would only change the language and validation portions of the GraphQL spec. Fields marked with ! will have a flag attached to them to indicate that the client believes they are required.

It is not. This information can be used by clients to do things like code generation or to alter their own behavior during execution.

[twof]

Option 3

Null propagates to nearest ?

In the event that a field marked with a ! is null, rather than propagation halting at the nearest Nullable parent as in the status quo, propagation will continue to the nearest parent marked with a ?. If a matching ? is not supplied, null propagates all the way to data. For the sake of code generation, all fields between a ! and it's matching ? could be Non-Nullable.

Example

Schema

type Business {
  name: String
  isStarred: Boolean
}

type Owner {
  business: Business
}

Query

{
    owner {
        business? {
            name
            isStarred!
        }
    }
}

If isStarred has a ! but returns null and business is marked with ?, the result will be:

{
    "data": {
       "owner": {
            "business": null
        }
    }
}

Example 2

{
    owner? {
        business {
            name
            isStarred!
        }
    }
}

Response

{
    "data": {
       "owner": null
    }
}

If there is no matching ?

{
    owner {
        business {
            name
            isStarred!
        }
    }
}

{
  "data": null
}

[twof]

Schema

type Query { a: A }
type A { b: B }
type B { field: Int! }

Query

query {
  a {
    b { field! }
  }
  a {
    b { field }
  }
}

Were a.b.field to be null, the first branch desires { data: null }, the second has {data: {a: {b: null}}}.

Does that work as a counter-example, or are you saying you think it's fine to merge in that case?

[benjie]

In this case, the a.b.field! will throw, causing the entire result to be null. This would be the same situation as if you had this kind of thing:

query {
  a {
    b {
      field
      fieldThatThrows
    }
  }
}

where a and b are non-nullable. I.e. even if field was present, because fieldThatThrows throws the entire response is blown up, so field merging has no issues (it's either fine, or it doesn't exist because something higher up caught it). Do you see what I mean?

[twof]

I'm not sure I follow. If a and b are non-nullable, then yes, I do see how you could argue that the fields could be merged without issue because the end result would be equivalent. But in my example, the behavior of one of the two fields would have to be selected in order to merge because they would create different responses.

[benjie]

Right, but the null would only occur where a ? had been explicitly placed, or the root. In either case, setting that location null would not invalidate the expectations of the client from a nullability perspective.

[twof]

Apologies for taking forever to respond here. I'm going to wait for our other discussion to settle and then come back to this one since the outcome of that one will have an impact on this.

[twof]

Hello! It's been a while. The Client Controlled Nullability RFC is now winding down in favor of True Schema Nullability, so I'll be closing CCN related issues, PRs, and discussions. All further discussion should be rerouted to one of the following:
#1394
graphql/nullability-wg#39
#1410
graphql/graphql-spec#1065

Additionally, we're in the process of removing the CCN experimental flag from graphql-js.

TL;DR of the new proposal(s) is that instead of allowing clients to adapt to imprecise schema definitions, our new approach is to find ways to allow schema authors to provide the precision that's been missing. There are a few different approaches to that which you can read about in the discussions above. Apollo and a couple other schema authors are in the process of putting together experiments, so if you'd like to have input or beta test the new proposal(s), reach out to us either in the Nullability Working Group, or in the #nullability-wg channel on Discord.