Satisfiability validation rule for non-intersecting runtime types in different subgraphs

[dariuszkuc]

Given following schemas

1. Interface example

// subgraph A
type Query {
  a: A @shareable
}

interface A {
  x: Int
}

type I1 implements A {
  x: Int
  i1: Int
}

// subgraph B
type Query {
  a: A @shareable
}

interface A {
  x: Int
}

type I2 implements A {
  x: Int
  i2: Int
}

2. Union Example

// subgraph A
type Query {
  e: E! @shareable
}

type E @key(fields: "id") {
  id: ID!
  s: U! @shareable
}

union U = A | B

type A {
  a: Int
}

type B {
  b: Int
}

// subgraph B
type E @key(fields: "id") {
  id: ID!
  s: U! @shareable
}

union U = C | D

type C {
  c: Int
}

type D {
  d: Int
}

Both examples above should result in a satisfiability error.

Apollo tests: link

[glen-84]

What is meant by "non-intersecting" here? I1 and I2 intersect on field x – must they have exactly the same set of fields?

It's possible that this could be implemented as a post-merge validation rule instead of a satisfiability validation rule.

For the union example, there's no intersection of member types, so I don't think that the union type would be merged?