@defer(if: null) misleading

[benjie]

Consider the following:

query ($shouldDefer: Boolean) {
  foo {
    ... @defer(if: $shouldDefer) {
      a
      b
      c
    }
  }
}

With the variables:

{
  shouldDefer: null
}

shouldDefer: null implies it shouldn't be deferred to the casual observer, but equally @defer(if: null) feels like it should be equivalent to @defer - it's not clear what the right behaviour should be here. The spec is inconsistent on this matter.

Since GraphQL doesn't differentiate between requiredness and nullability, maybe this should be @defer(unless: Boolean) instead? Or we could explicitly forbid null via @defer(if: Boolean! = true) or similar?

At the very least, what to do on null should be explicitly specified.

(Same arguments for @stream of course.)

Related comments on the spec PR: graphql/graphql-spec#742 (review)

[robrichard]

Changing if to Boolean! = true makes sense to me. I'm going to move forward with that suggestion unless there is any objection.

[glasser]

I agree.

Let's say that somebody writes

directive @defer(
  label: String
  if: Boolean = true
) on FRAGMENT_SPREAD | INLINE_FRAGMENT

by accident in schema SDL. (Or heck, let's say they're lazy and just write directive @defer on FRAGMENT_SPREAD | INLINE_FRAGMENT.) What should the server do in this case? Actually in general — I don't think the spec really explains what to do if the user defines a @defer or @stream directive that isn't precisely what the spec expects.

(I don't think just saying "if the directive doesn't precisely match the spec, it's an error or ignore it" makes sense — we may want to add new optional parameters to the directives later, and presumably we wouldn't want a server that knows about the new parameters to stop processing schemas which use the old definitions.)