Jesper Louis Andersen

While handling this case, also handle the issue 388 in the GraphQL specification. This issue handles how input coercion of more complex types are supposed to work in the specification....

A couple of things: * It is called `sync` because it synchronizes with the GraphQL engine. I like the name `notify_wait` the best of your alternative suggestions. Let's see what...

This task is all about verifying that the types of fields and the shapes of responses are equivalent. This ensures that you have a unambiguous query. Some of this is...

We have fixed one concern here because the default-resolver now lives outside the GraphQL engine. This allows a user to define their own default resolver, and it simplifies some of...

@gausby and I have an even better solution. * First we need to handle #180 so we have an input null type * Next, we should have the concept of...

This has relevance to #183 where the type extension language is being made explicit.

*Note:* The right solution is to invert the checking: Currently, we build a variable context and we use this to check that each variable use is valid in that context....

The "function specifications" on fragments are type signatures for fragments. This is handled in #107 after which we can simply solve this by building the appropriate test cases.

This is actually an interesting case where I'd have to read the spec in order to understand exactly what is going on. I don't know the rules of how the...

Since Jun2018 spec, this is now a bug. The details are in #166, and we can clarify how resolution should happen. The spec now: * accepts *not* providing a parameter...