graphql / graphql/graphql-spec
[Validation] Nested inline fragments may be unreachable
- Dominant language
- JavaScript
- Stars
- 14.6k
- Forks
- 1.2k
- PR merge metrics
- No merged PRs in 30d
Description
I'm not sure if this is the place to put this issue. It is about an unexpected behavior of the inline Type fragments in the current GraphQL spec.
Consider the GraphQL schema defined in the example page http://graphql.org/swapi-graphql. The following query is invalid as "Person" can never be of type "Vehicle" so the object cannot be spread.
```graphql
query {
allPeople {
people {
...on Vehicle {
id
}
}
}
}
```
Nevertheless, the following query is valid which seems to be counterintuitive
```graphql
query {
allPeople {
people {
...on Node {
...on Vehicle {
id
}
}
}
}
}
```
In this case the validity came from the fact that "...on Node" can be spread as a "Person" is always a "Node", and moreover, "...on Vehicle" can be spread in the scope of a "Node". This is counter intuitive since the "...on Node" is in the scope of "Person" which makes the "...on Vehicle" fragment to always be in the scope of the "Person"so anyway it cannot be spread. Executing this last query at http://graphql.org/swapi-graphql gives
{
"data": {
"allPeople": {
"people": [
{},
{},
.... (several times)....
{}
]
} } }
I think that this design would lead to some misunderstanding from users. I have thought on two possible options to deal with this:
1) Forbid the use of expressions of the form "...on Type1 { ...on Type2 { ... } }" in queries (that is, one cannot nest "...on Type"s fragments without a field selection.
or
2) Ensure that in every immediate nesting of "...on Type"s fragments, the nested Type is either equal, or an implementation, or part of a union of the outer Type. That is, for something of the form "...on Type1 { ...on Type2 { ... } }" one should force Type2=Type1, or Type2 be an implementation of Type1, or Type2 be part of the union Type1.
Contributor guide
Assessment
This issue has not been assessed yet.