Overview

We encountered a bug in production that has uncovered a mismatch in the relationship between optional fields with defaults and the Go types used to represent them. The parser should be corrected to add support for setting defaults on optional InputValues.

Current State

Consider this simple schema with one object:

schema {
  query: Query
}

type Query {
  buyIceCream(args: QueryInput): Boolean!
}

input QueryInput {
  flavor: String = "VANILLA"
}

and the corresponding resolver:

func (r *resolver) BuyIceCream(args struct{ Args *struct{ Flavor *string } }) bool {
	return true
}

The parsing method will reject this schema with this error could not unmarshal "VANILLA" (string) into *string: incompatible type.

Expected Behaviour

The expectation is that the parser is able to represent this schema and resolver combination and that all users of this library are able to set defaults on optional InputValues.

Further Notes & Workarounds

The common way to work around this is to use a non-pointer type to represent the optional argument. While the parser allows this, it can lead to runtime errors if a client supplies a (legal) null value for the field. This error message in this case is graphql: got null for non-null.

This also hopefully explains why we’d want optional fields with defaults in the first place. Including null as a possible input is sometimes the best way to represent our business domain.

I hope this write-up is sufficient. I can open a PR with some failing tests as a next step if that would be helpful. I’m going to continue working on solving the issue, but I thought that having the issue described here might help someone else who is seeing the same problem.