GraphQL validators fail on situation which can never happen

[mrtnzlml]

Hi! So I am actually not sure if this is a bug or not. But seems logical to me. I have the following query:

query ($abTestEnabled: Boolean = true) {
  allLocations(first: 10) {
    edges {
      node {
        id: code @include(if: $abTestEnabled)
        id(opaque: false) @skip(if: $abTestEnabled)
      }
    }
  }
}

(you can try it here)

As you can see, this query will either return variant A or variant B so always only one ID. However, GraphQL compains with the following error:

Fields \"id\" conflict because code and id are different fields. Use different aliases on the fields to fetch both if this was intentional.

But this situation will never happen. Is it maybe a bug in some validator?

[IvanGoncharov]

@mrtnzlml This expected behavior. According to the specification, the algorithm doesn't take @skip/@include or any other directives into account:
https://graphql.github.io/graphql-spec/draft/#sel-LALRFHCDHDFDDAAACDnBrwe

fieldA and fieldB must have identical sets of arguments.

In general, GraphQL validation doesn't take to account runtime values of query variables.
But in this case, it's boolean so both options are mutually exclusive so you are completely right that it can be statically analyzed.

However, we need to consider the complexity and runtime cost of such deep analyzes.
Taking into account that aliases were added to support querying the same field multiple times (see examples) and not as a response transformation mechanism, I don't think it's worth the added complexity and performance penalties.

But in any case, we can't change validation algorithm without change to GraphQL specification so if you still think it's important for GraphQL to handle this use case please open an issue here: https://github.com/graphql/graphql-spec