Issue Using Fragments on Union Types

[bannzai]

Expected Behaviour

Response JSON

{
  "data": {
    "Q": {
      "__typename": "A",
      "a": "1"
    }
  }
}

Actual Behavior

Actual Response JSON

{
  "data": {
    "Q": {
      "__typename": "A"
    }
  }
}

Minimal graphql.schema and models to reproduce

schema

type Query {
  Q(): U!
}

type A {
 a: String!
}
type B {
 b: Boolean!
}

union U = A | B

Query

query {
  Q {
    __typename
    ...F
  }
}

fragment F on U {
  __typename
   ... on A {
    a
  }
  ... on B {
    b
  }
}

Resolver

func (r *queryResolver) Q(ctx context.Context) (model.U, error) {
	return model.A{A: "1"}, nil
}

Description

I want to get for Expected Behaviour json when client request query.
But I can't receive Expected Behaviour json. So, It is not exists "a": "1" json field.
Please tell me if there is a solution on this.

[mbranch]

I ran into this as well, and I think the root issue has to do with fragment usage. The above query, with the fragment removed, does seem to work:

query {
  Q {
    __typename
    ... on A {
	  a
	}
    ... on B {
	  b
	}
  }
}

[mbranch]

I've found the issue can be resolved (though incorrectly) by omitting the following lines.

gqlgen/graphql/exec.go

Lines 62 to 64 in 5c870a4

	if !instanceOf(fragment.TypeCondition, satisfies) {
	continue
	}

It seems to me that a fragment on a union isn't truly supported.

(edit: a fragment on a union appears unsupported, but if the fragment is on a common interface over the union type, this will work as expected)

This is a very superficial look into this that may help someone with more knowledge understand the issue quickly. When I have some time, I may look into it further as we really like this tool so far, but this bug is a showstopper unfortunately.

[mbranch]

Following up on this, I see a related remark in pull request #335:

RFC probably doesn't handle the case where the interface is not generated, but the models are, what should happen there?

• This case is actually kind of insane, so upon further thought let's not handle it.

@lwc Would you mind weighing-in on this issue, your comment seems to suggest there's something fundamentally wrong with returning a list of heterogeneous types without an common interface. I don't see why, but maybe I'm missing something.