Fixes for incremenal delivery integration branch

[robrichard]

In a previous discussion we had decided to validation agains any overlapping stream fields. This has already been implemented in graphql-js for some time
See graphql/defer-stream-wg#100 and graphql/graphql-js#4342

Additionally there were two instances of completed result that was not missed and not renamed to incremental
completion notice

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: robrichard / name: Rob Richard (6cfe6b0)

[benjie]

Hmmm... "distinct members" may be doing a lot here. For example:

frag A on Foo {
  ...B
  ...B
}
frag B on Foo {
  blah @stream
}

might merge since B.blah is the same field twice, assuming that's what we mean by "distinct members", but

frag A on Foo {
  ...B
  ...C
}
frag B on Foo {
  blah @stream
}
frag C on Foo {
  blah @stream
}

would not, because B.blah != C.blah even though it seems that they should have the same result as in the previous example.

This is probably okay for @stream because it shouldn't really be fragment-merged in the same way regular fields would be (we want @stream to be used reasonably scarcely?)... but it warrants acknowledgement. It's a bit of a break from the norm for GraphQL.

[robrichard]

Yes this is the behavior we want. See the discussion here: graphql/defer-stream-wg#100

It becomes an issue when the stream, even with the same arguments has different selection sets. One fragment can influence the performance characteristics of the stream on another fragment, which is why we decided to prohibit this.

[benjie]

Hmmm... but what about:

frag A on Foo {
  ...B
  ...C
}
frag B on Foo {
  ...D @include(if: $var1)
}
frag C on Foo {
  ...D @defer(if: $var2)
}
frag D on Foo {
  blah @stream
}

Here, is A>B>D.foo seen as the same as A>C>D.foo? Are they distinct members?
... does it matter? 🤔 I suppose not...