Spec Bug...? ProvidedRequiredArgumentsRule fails to evaluate all potential runtime types

[yaacovCR]

Consider the following schema:

type Query {
  someInterface: SomeInterface
}

interface SomeInterface {
  echo(value: String! = "default"): String
}

type SomeType implements SomeInterface {
  echo(value: String!): String
}

As mentioned by @vepanimas at graphql/graphql-js#3214 => types implementing interfaces have to conform to their types, but not to their default values, and so the above is now considered valid.

Consider the following operation:

{
  someInterface {
    echo
  }
}

The ProvidedRequiredArgumentsRule as specified and implemented within the reference evaluation states that an argument for echo on SomeInterface is not required, because a default value exists, but at runtime, the execution portion of the spec and the implementation take default values from the concrete runtime type, ignoring the interface. The operation will validate successfully, but throw a runtime error.

Thoughts:

1. We either should (A) not allow default values on interface fields (because they are currently apparently never used) or (B) require that implementing types also have default values.
2. We can solve the validation/execution discrepancy either via option (B), or by (Z) changing the Validation Rule to inspect all the possible runtime types.

I think option (B) is a breaking change in terms of 1, because some schemas will break.
I think fixing the validation rule via option (B) or (Z) may also be a breaking change in terms of 2, because some operations will break => but does it count if it is a bug fix? Seems like it does, similar to #1059

[yaacovCR]

See graphql/graphql-js#4272 for a test that demonstrates the current reference implementation behavior.

[martinbonnin]

We either should (A) not allow default values on interface fields (because they are currently apparently never used)

TIL! So given this schema:

interface Displayable {
  thumbnailUrl(size: Size! = MEDIUM): String!
}

type Album implements Displayable {
  thumbnailUrl(size: Size! = LARGE): String!
}

type Query {
  displayable: Displayable
}

and this query:

{
  displayable {
    thumbnailUrl
  }
}

I will get the LARGE thumbnail always? Because there is only 1 concrete type and the interface default value is never used?

I find this surprising. The fact that the actual argument and the default value displayed by tooling such as graphiql, etc.. don't match feels pretty weird.

[yaacovCR]

The fact that the actual argument and the default value displayed by tooling such as graphiql, etc.. don't match feels pretty weird.

If we go with (B) for (1), the existence of a default value on an interface would be meaningful, because it would result in enforcement that implementing types also have default values, but the actual value of that default value would still not be useful, still leading to the weirdness you are noting ==> assuming that tools such as graphiql are not updated. We could extend (B) even further and require all the default values of the implementing types to be identical to the default value on the interface. This would also appear to be a breaking change for some schemas => and potentially not desirable.

[benjie]

Recreation using the reference implementation below; note that the schema and operation are both valid but that the resolver itself is never executed due to the behavior of CoerceArgumentValues() - i.e. this isn't a critical bug, but is something where stronger validation may be helpful. In particular, it feels like this schema should raise an error that the implementations should have a default since the interface does. I don't think the defaults have to necessarily align, though having them not align is potentially confusing.

import { buildSchema, graphqlSync, parse, print, printSchema, validate, validateSchema } from "graphql";

const schema = buildSchema(/* GraphQL */ `
  enum Size { MEDIUM LARGE }
  interface Displayable {
    thumbnailUrl(size: Size! = MEDIUM): String!
  }
  type Album implements Displayable {
    thumbnailUrl(size: Size!): String!
  }
  type Query {
    displayable: Displayable
  }
`);

{
  console.log();
  const errors = validateSchema(schema);
  if (errors.length > 0) {
    console.log("SCHEMA IS INVALID");
    console.dir(errors);
    process.exit(1);
  }
  console.log("SCHEMA IS VALID");
  console.log(printSchema(schema));
}

const source = /* GraphQL */ `
  {
    displayable {
      thumbnailUrl
    }
  }
`;

{
  console.log();
  const ast = parse(source);
  const errors = validate(schema, ast);
  if (errors.length > 0) {
    console.log("OPERATION IS INVALID");
    console.dir(errors);
    process.exit(1);
  }
  console.log("OPERATION IS VALID");
  console.log(print(ast));
}

const result = graphqlSync({
  schema,
  source,
  rootValue: {
    displayable() {
      return {
        __typename: "Album",
        thumbnailUrl(_, { size }) {
          return size;
        },
      };
    },
  },
});

console.log();
console.log("OPERATION RESULT");
console.log(result);

Output:

SCHEMA IS VALID
enum Size {
  MEDIUM
  LARGE
}

interface Displayable {
  thumbnailUrl(size: Size! = MEDIUM): String!
}

type Album implements Displayable {
  thumbnailUrl(size: Size!): String!
}

type Query {
  displayable: Displayable
}

OPERATION IS VALID
{
  displayable {
    thumbnailUrl
  }
}

OPERATION RESULT
{
  errors: [
    GraphQLError: Argument "size" of required type "Size!" was not provided.
        at getArgumentValues (node_modules/graphql/execution/values.js:192:15)
        at executeField (node_modules/graphql/execution/execute.js:483:48)
        at executeFields (node_modules/graphql/execution/execute.js:414:22)
        at completeObjectValue (node_modules/graphql/execution/execute.js:925:10)
        at completeAbstractValue (node_modules/graphql/execution/execute.js:806:10)
        at completeValue (node_modules/graphql/execution/execute.js:635:12)
        at executeField (node_modules/graphql/execution/execute.js:500:19)
        at executeFields (node_modules/graphql/execution/execute.js:414:22)
        at executeOperation (node_modules/graphql/execution/execute.js:344:14)
        at execute (node_modules/graphql/execution/execute.js:136:20) {
      path: [Array],
      locations: [Array],
      extensions: [Object: null prototype] {}
    }
  ],
  data: [Object: null prototype] { displayable: null }
}

[benjie]

This isn't quite an RFC yet, but it should be.

[Keweiqu]

@jjergus this might be interesting to you.

[benjie]

Here are the options I see:

1. Forbid interface fields from having default values on their arguments.
2. If an interface field argument has a default value, each implementation must have the exact same default value.
3. If an interface field argument has a default value, each implementation must have a default value, but it need not be the same.

(Note: additional thought may need to be put into nullable arguments with a default = null).

I'm currently in favour of option (3) since it's non-breaking. The fact that the specific default value is not enforced to be identical across implementations is distasteful, but we can encourage people to ensure they're the same with a SHOULD (rather than MUST) rule. This can be enforced through tools like graphql-eslint.

(1) is a breaking change because querying the field on an interface would now always require the argument to be specified, which would break existing queries that do not specify the argument here.

(2) is arguably breaking because the default value used in these positions may have to change, which could change the meaning of existing queries (though they would remain valid). This is relatively minor, but it's just enough for me to favour option (3) over option (2) which was my initial favourite.

(3) is non-breaking from a client perspective (the only perspective that the spec generally cares about):

• With this new schema validation rule, a schema that has a default on an interface field argument but no default on an implementation would become invalid (and thus could not be deployed).
• Schema designers would need to fix the schema by applying default values to each affected implementation's field's argument.
• From a client perspective, non-nullable arguments (and nullable arguments for that matter) gaining a default is a non-breaking change - no existing queries would be invalidated or have their meaning impacted by this change.

I propose we move ahead with option 3.

[yaacovCR]

Option 1 may not be a breaking change from a client perspective => because we would in tandem change the validation rule to the correct form, which would make sure that an argument was included unless every possible runtime type has a default.

A query which was not specifying an argument would have failed previously at runtime if defaults were not specified for all runtime types, but would validate and succeed at runtime if that indeed was the case.

I think!