Graphql-js: Querying same field w/ and w/o attributes for different union types results in error

[mnylen]

Query:

{
  curatedList {
     ...on Program {
        title(lang: "fi")
     }

     ...on Article {
        title
     }
  }
}

Error:

Fields title conflict because they have differing arguments.

Should it really work like that, or is this a bug?

Article and Program are both members of union type Content

[leebyron]

This is currently working as designed, but feedback is welcome.

The design goal here is to make the resulting response unambiguous.

If for example, Article and Program were both Interfaces that one type adhered to, it would be unclear which variant of "title" was being requested.

[schrockn-zz]

This is very deliberate. Any time that two fields that "merge" can _potentially_ return different results we do not allow this.

Imagine if "title" returned "foo" and "title(language: fi" returned "bar" which value would the "title" key be?

[schrockn-zz]

If you wish to query for both you should alias at least one of the fields to be unambiguous.

[leebyron]

I think we could probably improve this if two fields are known to never "merge". In this case, the two types are Object types and in no condition would both "title" fields be queried for the same object.

We should be a bit smarter about this (likely common) case

[mnylen]

Is there any possibility for confusion when using the ...on TypeName { ... } query, even if interfaces were used instead of union types?

If there was a SearchResult interface that defined a field pictureUrl(width: Int) and a title. The interface is implemented by Page and Image. Wouldn't it be a valid use case to do something like this:

 ...on Page { title, pictureUrl(width: 120) }
 ...on Image { title, pictureUrl(width: 600) }

This would also result in error with current implementation.

[mnylen]

Actually, even if the query was something like

title,
pictureUrl(width: 120),
...on Image { pictureUrl(width: 600) }

that'd still be pretty easy to reason about: select 120px picture url for anything that isn't an Image, and 600px for Image.

[mnylen]

The only problem I can think of is with case where an interface defines a field with some set of args and it's implemented with different set of args. For example, if Article and Program implemented a HasTitle interface with a title field w/o args, it would clearly be an error for Program to have one with language arg.

In this case it would be pretty hard to respond to query like ...on HasField { title }, because you can only apply that query to Article - Program needs the language arg.

But this should be a compile time check to ensure you can't create such schema in the first place. Instead of it happening on query time.

[leebyron]

title,
pictureUrl(width: 120),
...on Image { pictureUrl(width: 600) }

This case definitely presents an issue, since if you have an object which is of type Image, then it's unclear what width your pictureUrl field will be prepared with, both the field with 120 and with 600 would apply. This is exactly the ambiguity we're trying to avoid.

[mnylen]

@leebyron, I think it's quite intuitive way of saying just give me 120px preview image for search results that aren't an Image and 600px for Images.

You could think of it as ...on Image { ... } "block" giving a precedence over anything else in this query, because it applies to a specific type. So, for Image objects the pictureUrl(width: 600) would have higher precedence because it was requested inside an ...on Image { ... } block.

[clentfort]

We shouldn't add more ways to shoot ourself into our feet! We already have very powerful features in the language to allow very flexible queries!
In your SearchResult example the different result types must be treated in different ways anyway (why else would they return images of different sizes if not to be displayed differently), so you have to do checks when iterating over the results. Using an alias in the ... on Image { ... } fragment increases readability and reduces unpredictable behavior.

[mnylen]

Can you explain what part you do consider as shooting you into feet?

The precedence thing might be such, but I don't think my original example with program and article title is that unreasonable.

[leebyron]

I'll have this out in the next npm release soon

[mkochendorfer]

@leebyron So it appears this issue was addressed for aliases but never for actual type definitions. Consider this example schema:

type Query {
  components: [Component]
}
interface Component {
  id: ID
}
type ComponentOne implements Component {
  id: ID
  background: String
}
type ComponentTwo implements Component {
  id: ID
  background: ComponentTwoBackground
}
type ComponentTwoBackground {
  color: String
  image: String
}

With this schema the following query would be very legitimate:

query {
  components {
    id
    ... on ComponentOne {
      background
    }
    ... on ComponentTwo {
      background {
        color
        image
      }
    }
  }
}

However, this will always give you an error about the types of the background fields not matching . Any reason why this https://github.com/graphql/graphql-js/blob/master/src/validation/rules/OverlappingFieldsCanBeMerged.js#L603 type check cannot be moved up inside of the if (!areMutuallyExclusive) { conditional?

[IvanGoncharov]

Any reason why this /src/validation/rules/OverlappingFieldsCanBeMerged.js@master#L603 type check cannot be moved up inside of the if (!areMutuallyExclusive) { conditional?

@mkochendorfer Response fields should have predictable type it should be the single type not the combination of string and ComponentTwoBackground. Also implemented according to GraphQL Specification: https://graphql.github.io/graphql-spec/draft/#SameResponseShape()

[mkochendorfer]

@IvanGoncharov They do have predictable types depending on the parent type, so I do not really understand your statement. I will also add that the behavior was already changed for aliases to allow this very thing, so I do not see how this is any different.

[mike-marcacci]

@mkochendorfer as @IvanGoncharov said, this is correct by the spec. Your example is actually one of few remaining areas of the spec that rubs me the wrong way; I definitely see its utility in the context of implementing parsers in certain languages, but with only a cursory analysis I found the restriction unnecessarily, given that client limitations shouldn't limit the abilities of the server (instead, they can just add aliases to their queries when they enter such a scenario, as all clients must do now).

I've currently got two projects I'm trying to champion for GraphQL (implementation of interfaces by interfaces and big TS changes), but as soon as one of these wraps up, I'm going to try to formalize a case for removing this restriction, and present it to the working group.

[mkochendorfer]

Yeah, I guess what I am fundamentally saying is that based on https://github.com/graphql/graphql-js/issues/53#issuecomment-121337250 and the resulting PR https://github.com/graphql/graphql-js/pull/229 it seems like the spec is already our of sync with this implementation. That original PR to address this issue seems like it would have worked for my case actually as it just exits immediately if the parent types differ. That code has since been changed causing my issue to resurface. https://graphql.github.io/graphql-spec/draft/#example-54e3d seems like a fundamentally wrong counter example based on all of the above, so if that means the spec needs to be updated to get this corrected, then I am all for it.

Is there some reason behind this restriction in the spec?

[jedwards1211]

Name one other type system that has a union type that requires fields of the unioned types to match...this was a nasty surprise and it makes me angry. And the fact that it was a deliberate decision even moreso.

In my case I had to types that unioned just fine until today, when I needed to make a field on one of them optional. Now I have to do extra work to de-alias the conflicting field in the query result 🙁

[jedwards1211]

@schrockn-zz

Imagine if "title" returned "foo" and "title(language: fi" returned "bar" which value would the "title" key be?

Whichever one corresponds to the __typename of the resolved object...Flow and TS are perfectly capable of representing union types where the unioned objects have fields with the same name and different types:

type Program = {
  __typename: 'Program',
  title: 'foo',
}
type Article = {
  __typename: 'Article',
  title: 'bar',
}
type CuratedListItem = Program | Article

And as I mentioned in my above comment, I don't know of any language whose type system is incapable of representing a union where field types mismatch.

Even if you're not querying the __typename field there would often be ways to do type refinements in Flow or TS with runtime checks, but if that proved difficult you would just solve it by including __typename in the query. I fail to see how the different field types would actually cause problems.

[jedwards1211]

@IvanGoncharov

it should be the single type not the combination of string and ComponentTwoBackground

Well GraphQL is also weird to me in that it only allows object types to be unioned. This issue seems like an unintended consequence of that design decision.
All other type systems with unions that I'm aware of allow primitive types to be unioned as well, if numbers and strings aren't first-class objects to begin with.
If GraphQL allowed primitive types to be unioned there would be nothing weird about the field being a combination of string and ComponentTwoBackground.