1.3.1Coercing Allowed Types

A filter argument is a field argument which has the @limitTypes directive applied.

The input to the filter argument is a list of strings, however this must be made meaningful to the resolver such that it may perform its filtering – thus we must resolve it into a list of valid concrete object types that are possible in this position.

The coerced list of valid concrete object types are the allowed types.

Example № 6interface Fish {
  swimSpeed: Int!
}
  
type Goldfish implements Pet & Fish {
  name: String!
  swimSpeed: Int!
}

type Haddock implements Fish {
  swimSpeed: Int!
}

Example № 7{
  allPets(only: ["Fish"]) {
    ... on Goldfish {
      swimSpeed 
    }
  }
}

Counter Example № 8{
  allPets(only: ["Haddock"]) {
    ... on Fish {
      swimSpeed
    }
  }
}

1.3.2Allowed Types Restriction

Enforcement of the allowed types is the responsibility of the resolver called in ResolveFieldValue() during the ExecuteField() algorithm.

When the field returns an abstract type, the collection is this type. When the field returns a list of an abstract type, the collection is this list. When the field returns a connection type over an abstract type, the collection is the list of abstract type the connection represents.

The resolver must apply this restriction when fetching or generating the source data to produce the collection. This is because the filtering must occur prior to applying pagination logic in order to produce the correct number of results.

When a field with a @limitTypes argument is being resolved:

• Let limitTypesArgument be the first argument with the @limitTypes directive.
• If no such argument exists, no further action is necessary.
• If argumentValues does not provide a value for limitTypesArgument, no further action is necessary.
• Let limitTypes be the value in argumentValues of limitTypesArgument.
• If limitTypes is null, no further action is necessary.
• Let abstractType be the abstract type the collection represents.
• Let allowedTypes be CoerceAllowedTypes(abstractType, limitTypes).

1.4.1Filter Argument Value Validation

Each member of the filter argument value must exist in the type system and be a possible return type of the field.

For example, the query below must yield an execution error – since LochNessMonster is not a type that exists in the example schema.

Counter Example № 9{
  allPets(only: ["Cat", "Dog", "LochNessMonster"]) {
    name
  }
}

When used, this algorithm must be applied before ResolveFieldValue().

1.4.2Field Collection Validation (wip)

For example, the following query must raise an execution error since Mouse does not appear as a value in allowedTypes

Counter Example № 10{
  allPets(only: ["Cat", "Dog"]) {
    ... on Cat { name }
    ... on Dog { name }
    ... on Mouse { name }
  }
}

1.4.3Field Response Validation (wip)

For example, given a filter argument of ["Cat", "Dog"], the following would be invalid since allPets contains Mouse:

Counter Example № 11{
  "data": {
    "allPets": [
      { "__typename": "Cat", "name": "Tom" },
      { "__typename": "Mouse", "name": "Jerry" }
    ]
  }
}

...is this even possible? this assumes that client asks for __typename which isn’t guaranteed. https://spec.graphql.org/draft/#ResolveAbstractType() likely is not possible since this logic is intended to be run generically as a middleware – i.e after the field has completed, and the in-memory object representation has been converted into json blob (potentially without __typename)

or can we look at using __resolveType()?