Default value declared via SDL may not introspect correctly

[leebyron]

One interesting aspect here is that a default value declared via SDL is coerced twice:
Once via valueFromAST and then again via coerceInputValueImpl. Is my reading here correct?

I am not really sure this is a problem, but I wanted to call that out.

Originally posted by @andimarek in #3049 (comment)

That's a good call out. Coercing more than once should be safe, assuming that coerce(X) == coerce(serialize(coerce(X)))

However I think this is likely exposing a real (but maybe low-impact) bug, even before this diff. Default values are exposed via introspection and are not expected to include nested default values:

input A {
  a: B = {}
}

input B {
  c: Int = 0
}

When introspecting A.a, we should see "defaultValue": "{}" but if I read correctly likely will see "defaultValue": "{c:0}"

If you were to re-print this SDL after introspection, you'd have:

input A {
  a: B = { c: 0 }
}

which broke the original intent.

Executed results would be correct, however schema representation would be off.

Notably, constructing the schema programmatically would not encounter this bug - only using AST creation would because of how valueFromAST works.

[andimarek]

I think that ties back to the missing functionality of printing an Ast value: #1817

[andimarek]

@leebyron I think in that case specifically we are looking at parseValue(parseLiteral(x)) == parseLiteral(x) as the first coercion is parsing the Literal and then it gets coerced again via parseValue (treated like a variable value lets say).

[andimarek]

Looking at GraphQL Java we have the same challenge around applied Directives in a Schema.
e.g.:

type Query {
  foo: String @bar(json:  {a: "a", b = "b"})
}

cc @IvanGoncharov How does GraphQL.js handle that? I didn't see any specific code to add an applied directive to a schema element. Is this possible programmatically without defining a SDL?

[yaacovCR]

Closed by #3810