Inline fragment with omitted type misses fields

[xenrox]

What happened?

Tried to include an inline fragment with no type specified. According to the specification example 24 that should work. But the fields of the included fragment are not returned by the server.

What did you expect?

That the inline fragment fields are returned if the include condition is true.

Minimal graphql.schema and models to reproduce

type Job {
  id: Int!
  manifest: String!
  note: String
  image: String!
}

type Query {
  job(id: Int!): Job
}

Working query:

query {
    job(id: 640) {
        id
        manifest
        ... on Job @include(if: true) {
            note
            image
        }
    }
}

Output:

{
  "data": {
    "job": {
      "id": 640,
      "manifest": "omitted",
      "note": "Arch rebuild",
      "image": "archlinux"
    }
  }
}

Non-working query:

query {
    job(id: 640) {
        id
        manifest
        ... @include(if: true) {
            note
            image
        }
    }
}

Output:

{
  "data": {
    "job": {
      "id": 640,
      "manifest": "omitted"
    }
  }
}

versions

• gqlgen version?
  0.16.0
• go version?
  1.17.7
• dep or go modules?
  go modules

Because sel.TypeCondition is an empty string here the inline fragment gets wrongly left out.

[phughes-scwx]

I have come across this same issue myself, as mentioned in issue #3381.

Versions

• go run github.com/99designs/gqlgen version: v0.17.56-dev
• go version: go version go1.22.5 darwin/arm64

---

I have determined that this bug is caused during field collection here:

gqlgen/graphql/executable_schema.go

Line 45 in 1040b92

if len(satisfies) > 0 && !instanceOf(sel.TypeCondition, satisfies) {

This fails to follow the specs algorithm (specifically this step) by not checking if there is a fragmentType (sel.TypeCondition) to test with DoesFragmentTypeApply.

Note: This may not have been noticed previously because omitting a type condition works for the most common operation directives @skip and @include. However this is because they are handled before the DoesFragmentTypeApply/instanceOf check, which also seems to me to not follow the spec directly: they might come in to effect when applied to a subset of types but not one that is actually returned by the given query. I have not gone to the effort yet of confirming this behavior.

All of this has been difficult to recreate and also just to follow, so I would like to submit a PR, if you think I've correctly identified the problem, that fixes this issue, follows the specification's algorithm more closely, and also adds an _examples directory for using @defer to help people who want to use it.

[phughes-scwx]

This was addressed in #3384 and an explicit test case is added with #3399. If these are both merged I think this issue (and issue #3252) can be closed @StevenACoffman.