Error from GraphQLScalarType is not properly propagated to formatError hook #7178
Comments
|
So it looks to me that the information is lost inside (I think maybe that line should say This change was introduced in graphql v14.5.0 in graphql/graphql-js#2062 I think. What's a bit confusing to me is that this ever worked (with graphql 14.5 or newer). You say it works when using the Note that As a workaround for now you could do this: You'll then end up with and the second argument err2 has an originalError field equal to I think this is close to what you want... though arguably our thing that adds BAD_USER_INPUT should only do that if there's not already a However it does feel like the main issue is that graphql-js should use the error you threw as originalError if it has no originalError on it... |
|
Hi @glasser, thank you for your quick response. I tried again the example from docs and it does not work either (sorry for confusion, on the first try I was getting That trick with |
Previously, the only fields observed on an error thrown by (for example) parseValue were `message` and `originalError`. Now, if an error has no `originalError`, it is itself used as the original error. Addresses an issue raised in apollographql/apollo-server#7178
Adding `BAD_USER_INPUT` is a nice default (and overrides the inappropriate default of `INTERNAL_SERVER_ERROR`) but if somebody has set a `code` already, we shouldn't override. (Note that there's a separate issue where graphql-js throws out extensions from the thrown error itself and only pays attention to extensions on the error's originalError; we're trying to fix that in graphql/graphql-js#3785 but this is orthogonal.) Fixes #7178.
|
I've filed #7183 to fix the "we write |
…7183) Adding `BAD_USER_INPUT` is a nice default (and overrides the inappropriate default of `INTERNAL_SERVER_ERROR`) but if somebody has set a `code` already, we shouldn't override. (Note that there's a separate issue where graphql-js throws out extensions from the thrown error itself and only pays attention to extensions on the error's originalError; we're trying to fix that in graphql/graphql-js#3785 but this is orthogonal.) Fixes #7178. Co-authored-by: Trevor Scheer <trevor.scheer@gmail.com>
Previously, the only fields observed on an error thrown by (for example) parseValue were `message` and `originalError`. Now, the error itself is used as the `originalError`; this may be mildly backwards-incompatible if you added extensions on the error itself which you for some reason wanted to disappear, but that seems unlikely. Addresses an issue raised in apollographql/apollo-server#7178
Hello,
we have a problem when throwing a
GraphQLErrorfromGraphQLScalarTypein the new apollo v4. Before (in v3) it properly propagated the error intoformatErrorhook but now it always changes itsextensions.codetoBAD_USER_INPUTand removes all additional fields.This is happening only on errors thrown from
GraphQLScalarType(e.g. errors from mutation/query resolvers work just fine) and only when we define GQL schema usingGraphQLSchema. I tried this example where the schema is defined usingtypeDefsandresolverskeys and it also worked.Here is the code where you can reproduce the error.
And here is the output.
I would expect the error received in
formatErrorhook to haveextensions.code === 'CUSTOM_ERROR_CODE'andextensions.extraErrorField === 123.Is there anything we missed? Thank you for any help.
The text was updated successfully, but these errors were encountered: