Interface inline fragment on union types results in panic.

[marksauter]

Error

Given:

interface Node {
  id: ID!
}

type A implements Node {
  id: ID!
  a: String!
}

type B implements Node {
  id: ID!
  b: String!
}

type C implements Node {
  id: ID!
  c: String!
}

union ABC = A | B | C

query {
  search(input: InputType!): ABC
}

If I make the following query to this mock api:

{
  search(input: { ... }) {
    ... on A {
      a
    }
    ... on B {
      b
    }
    ... on C {
      c
    }
    ... on Node {
      id
    }
  }
}

I get a panic error that Node does not implement ABC, originating from the following line of code:

graphql-go/internal/exec/selected/selected.go

Line 170 in bb97385

panic(fmt.Errorf("%q does not implement %q", frag.On, e.Name)) // TODO proper error handling

Expected

I expect the Node inline fragment to resolve just fine, because A) relay makes queries of this nature via its api, and B) each type in the union implements the Node interface.

Probable source of the error

Looking through the code I can see - correct me if I'm wrong - that the type assertion is only checking for possible types for the union. It is not checking if A) the inline fragment is an interface type, or if B) the union objects implement said interface.

Update

I've decided to just make all my union types into interface types for the time being.

[marksauter]

Found a solution to a related problem that prevented me from applying an interface fragment to an object that implements said interface. If the fragment is an interface type, then check if the resolvable.Object implements the interface. Could probably update this to include a check if the resolvable.Object is of type union, then check if all the possibleTypes implement the interface.

func applyFragment(r *Request, e *resolvable.Object, frag *query.Fragment) []Selection {
	t := r.Schema.Resolve(frag.On.Name)
	face, ok := t.(*schema.Interface)
	if !ok && frag.On.Name != "" && frag.On.Name != e.Name {
		a, ok := e.TypeAssertions[frag.On.Name]
		if !ok {
			panic(fmt.Errorf("%q does not implement %q", frag.On, e.Name)) // TODO proper error handling
		}

		return []Selection{&TypeAssertion{
			TypeAssertion: *a,
			Sels:          applySelectionSet(r, a.TypeExec.(*resolvable.Object), frag.Selections),
		}}
	} else if ok && len(face.PossibleTypes) > 0 {
		for _, t := range face.PossibleTypes {
			if t.Name == e.Name {
				return applySelectionSet(r, e, frag.Selections)
			}
		}
		panic(fmt.Errorf("%q does not implement %q", e.Name, frag.On)) // TODO proper error handling
	}
	return applySelectionSet(r, e, frag.Selections)
}

[nuknal]

I had met the same problem. Is there any plan to fix this in the future version?

[pavelnikolov]

A PR would be welcome. After reading this: https://graphql.org/learn/schema/#union-types
We might as well need to add an example query in our starwars schema that satisfies this:

Also, in this case, since Human and Droid share a common interface (Character), you can query their common fields in one place rather than having to repeat the same fields across multiple types:

{
  search(text: "an") {
    __typename
    ... on Character {
      name
    }
    ... on Human {
      height
    }
    ... on Droid {
      primaryFunction
    }
    ... on Starship {
      name
      length
    }
  }
}

Note that name is still specified on Starship because otherwise it wouldn't show up in the results given that Starship is not a Character!