hideSchemaDetailsFromClientErrors should trap coercion errors arising from query variable bindings

[wabrit]

When issuing a query such as query { noSuchField }, and passing hideSchemaDetailsFromClientErrors: true to the ApolloServer constructor, the Apollo strips "did you mean" suggestions from the error response as expected.

However, when the error arises from a query variable coercion error, the "did you mean" suggestion is not stripped from the error message.

This can be worked around using a suitable error formatter, but the docs should at least highlight that the hideSchemaDetailsFromClientErrors setting does not apply to this case.

Example Scenario

1. Create an ApolloServer with the hideSchemaDetailsFromClientErrors setting set to true
2. Invoke a query e.g. query GetUser($filter: UserFilter!) { users(filter: $filter) { id } }
3. Pass in variables { "filter": { "nam": "Bob" } } where the filter field nam is a mispelling of the true field UseFilter.name

The returned error message will be of the form

"$filter" got invalid value { nam: "Bob" }; Field "nam" is not defined by type "UserFilter". Did you mean "name"?

which contains the Did you mean schema hint; this is likely because the error is trapped during value coercion, and as a result:

• Apollo’s validationDidStart() hook doesn’t get called with these errors
• The internal ApolloServerPluginDisableSuggestions plugin never sees the error
• The error passes through unmodified to the client

[glasser]

Once GraphQL.js v17 is released and we can put out a future version that depends on it, both things this depends on can be fixed much better, because GraphQL.js v17 has explicit support for disabling "did you mean" and for separating variable coercion from the rest of execution. (These are probably the two hackiest parts of Apollo Server right now.)

Until then I'd rather this get fixed instead of documented. We currently only look at hideSchemaDetailsFromClientErrors in the validation phase, and these errors happen later. We could add a check-and-clean around the place where we call isBadUserInputGraphQLError.

I think this is a bugfix so I think we could make this fix in a minor version rather than needing to be a major version.

[abscondment]

I see similar behavior when passing invalid enum values as variables, e.g.

{
  "enumType": "FakeEnumValue"
}

->

"Variable \"$enumType\" got invalid value \"enumType\"; Value \"FakeEnumValue\" does not exist in \"ExampleEnum\" enum. Did you mean the enum value \"RealEnumValue\"?"

I'm not sure if this is also considered a variable coercion error, or if there are other paths for hideSchemaDetailsFromClientErrors that need to be fixed, too.