Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GraphQL validators fail on situation which can never happen #2189

Closed
mrtnzlml opened this issue Sep 20, 2019 · 1 comment
Closed

GraphQL validators fail on situation which can never happen #2189

mrtnzlml opened this issue Sep 20, 2019 · 1 comment
Labels

Comments

@mrtnzlml
Copy link

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
Copy link
Member

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants