0.8.x breaking change with errors thrown from scalar resolvers #821
Comments
|
@thebigredgeek the PR in question is this one, and I believe it was very much intentional. Just looking at the error message and the PR, I'm guessing that maybe the error isn't being thrown from a resolver, but from |
|
Yes, you are correct. Is |
This was referenced Dec 7, 2017
leebyron
added a commit
that referenced
this issue
Dec 14, 2017
This generalizes the "arguments of correct type" and "default values of correct type" to a single rule "values of correct type" which has been re-written to rely on a traversal rather than the utility function `isValidLiteralValue`. To reduce breaking scope, this does not remove that utility even though it's no longer used directly within the library. Since the default values rule included another validation rule that rule was renamed to a more apt "variable default value allowed". This also includes the original errors from custom scalars in the validation error output, solving the remainder of #821. Closes #821
leebyron
added a commit
that referenced
this issue
Dec 14, 2017
This generalizes the "arguments of correct type" and "default values of correct type" to a single rule "values of correct type" which has been re-written to rely on a traversal rather than the utility function `isValidLiteralValue`. To reduce breaking scope, this does not remove that utility even though it's no longer used directly within the library. Since the default values rule included another validation rule that rule was renamed to a more apt "variable default value allowed". This also includes the original errors from custom scalars in the validation error output, solving the remainder of #821. Closes #821
leebyron
added a commit
that referenced
this issue
Dec 14, 2017
This generalizes the "arguments of correct type" and "default values of correct type" to a single rule "values of correct type" which has been re-written to rely on a traversal rather than the utility function `isValidLiteralValue`. To reduce breaking scope, this does not remove that utility even though it's no longer used directly within the library. Since the default values rule included another validation rule that rule was renamed to a more apt "variable default value allowed". This also includes the original errors from custom scalars in the validation error output, solving the remainder of #821. Closes #821
leebyron
added a commit
that referenced
this issue
Dec 14, 2017
This generalizes the "arguments of correct type" and "default values of correct type" to a single rule "values of correct type" which has been re-written to rely on a traversal rather than the utility function `isValidLiteralValue`. To reduce breaking scope, this does not remove that utility even though it's no longer used directly within the library. Since the default values rule included another validation rule that rule was renamed to a more apt "variable default value allowed". This also includes the original errors from custom scalars in the validation error output, solving the remainder of #821. Closes #821
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It appears that 0.8.x introduced a breaking change with errors thrown from scalar resolvers. Upon upgrading, it appears that errors thrown from scalar resolvers (exclusively) have, by the time they have reached
formatErrors, been transformed into a shape like:[1] [1] message: 'Variable "$input" got invalid value {"stripeCardName":"asdasdada","stripeCardNumber":"42424242424223113","stripeCardExp":"00/00","stripeCardCVC":"233"}.\nIn field "stripeCardNumber": Expected type "CreditCardNumber", found "42424242424223113": The credit card number you entered appears to be invalid.', [1] [1] locations: [ { line: 1, column: 28 } ], [1] [1] path: undefined }where the original error message was "The credit card number you entered appears to be invalid", and the original error object contained a bunch of useful meta data as an error created with apollo-errors that instructed the client about validation issues (in this case, a credit card number that isn't valid according to ccn validation algorithms).
Was this intended? It seems strange to force an error format like this, especially as a breaking change.
It looks like this might have been the change, according to the v0.8.0 release changelog
The text was updated successfully, but these errors were encountered: