failure to require leaf field selection when using fragments

[VladimirAlexiev]

Assume a simple schema like this:

interface Character {name:String!}
type Human implements Character {name:String!}
type Droid implements Character {name:String!}
type Query {
  characters: [Character!]
}

This query is not valid because it does not select down to leaf (scalar) fields (see https://graphql.github.io/graphql-spec/draft/#sec-Leaf-Field-Selections):

{characters {
}}

Then why is this query valid? It selects a scalar field, but only for Human. It'd return Droids without any fields i.e. {}.

{characters {
   ... on Human {name}
}}

I asked the question on:

• StackOverflow #graphql: https://stackoverflow.com/questions/57623570/is-this-graphql-query-valid
• ReactiFlux #graphql: https://discordapp.com/channels/102860784329052160/103315563073269760
• Slack: https://graphql.slack.com/archives/C044QJ51J/p1566553730281700

andrewingram replied: it's valid, which can seem counter-intuitive. it's valid in graphql-js, which is aligned with the spec.

I think the query exposes an omission in the spec?

[TDiazT]

Actually, I think that it is valid. The spec says :

• If selectionType is an interface, union, or object
  The subselection set of that selection must NOT BE empty

It simply states that it must contain a subselection (could be an inline fragment as in your example). It doesn't specify that its subselections must be leaf field selections.

I agree that in essence it should actually contain leaf selections for every possible subtype of the field's return type (e.g Human and Droid in your scenario), otherwise it could return an empty response. For instance, if there are no humans and 3 droids in your database then it would return:

{
    "character" : [{}, {}, {}] 
}

This also happens with union types, you are not obliged to specify each concrete type and therefore can get empty results.

I imagine there must be some reason related to fragments ?

[sungam3r]

Interesting question.

[IvanGoncharov]

@VladimirAlexiev Thanks for the question 👍

This query is not valid because it does not select down to leaf (scalar) fields (see graphql.github.io/graphql-spec/draft/#sec-Leaf-Field-Selections):

We have an RFC that makes it valid, please see #674

Then why is this query valid?

Because it's a common use case to get only data for certain types from union/interface.
We shouldn't force users to ask for additional data just to make validator happy.

I agree that in essence it should actually contain leaf selections for every possible subtype of the field's return type (e.g Human and Droid in your scenario), otherwise it could return an empty response.

In general empty selection was forbidden because most of the time they were used unintentionally. Forbidding empty objects was never a goal here.

Moreover adding such requirement will break a lot of existing queries that contradicts "Backwards compatibility" principle: https://github.com/graphql/graphql-spec/blob/master/CONTRIBUTING.md#guiding-principles