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.