Intent of uniqueness rules for multiple extensions

[benhead]

In the spec, many type validation rules require uniqueness of various elements when applying an extension. For example, this, from 3.8.1 Union Extensions:

All member types of a Union type extension must not already be a member of the original Union type.

and this, from 3.6.3 Object Extensions:

Any interfaces provided must not be already implemented by the original Object type.

Is this intended to also disallow multiple extension clauses adding the same element, or is the intent only that extensions must not duplicate the "original" declaration?

Again, I hope examples will help clarify.... This is clearly a violation, because the "original" declaration and the extension both specify member Bar:

union MyUnion = Foo | Bar
extend union MyUnion = Bar | Baz

Is this also a violation? Both extension clauses specify member Bar, but the "original" does not.

union MyUnion = Foo
extend union MyUnion = Bar | Baz
extend union MyUnion = Bar | Qux

[benjie]

It may be poorly worded, but I think essentially the "original type" is replaced by the extension. So in this example:

union MyUnion = Foo
extend union MyUnion = Bar | Baz
extend union MyUnion = Bar | Qux

After line one, MyUnion is newly created, with union MyUnion = Foo
After line two, MyUnion has been replaced such that now union MyUnion = Foo | Bar | Baz
Line three would be invalid since the "original" MyUnion type we're extending is the type defined on line 2, and already contains Bar.

I think the usage of the word "original" here may be problematic, really we're just referencing the "current type with this name before the extension is applied" rather than "the first instance of this type being defined ever".

What happens if you feed this example into the reference implementation?

[benhead]

Thanks, this was my reading as well, but it matters to an implementation I'm working on, so I wanted to confirm.

[benjie]

I've suggested some spec edits here and also confirmed that GraphQL.js' interpretation is in line with my own: #1123

Thanks for raising this @benhead.