-
Notifications
You must be signed in to change notification settings - Fork 575
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
throw from resolver should not be logged #199
Comments
Thanks a lot for bringing this up @steida. If I'm not mistaken then it's actually not Do you want a setting to disable error logging or rather an easy way to catch all of these errors and implement your own handling? |
@schickling Own handling, definitely. Do you have any idea how? |
@timsuchanek @divyenduz can you describe a couple of approaches here? |
@steida you can install |
Actually, I moved all errors to the schema where it belongs. And https://github.com/maticzav/graphql-shield soon allow controlling logging I guess. |
@schickling Feel free to close it. Thank you. |
Hello @danutzcodrescu After seen your comment, I also looked about this one #167 After make some test by adding |
@johannpinson Hi, how do you manage to make the error response log disappears? I tried the following:
doesn't work.. |
hey @rvlewerissa Actually I reviewed my workflow and I use Apollo Server v2 directly, so I didn't have even more this problem 😉 |
@johannpinson Ah I see.. Thanks |
I'd like to vote against this actually, or at least for a modified version. This has the very unfortunate side effect of hiding "legitimate" errors, without any record of them. That makes things extremely hard to reproduce and debug when fit hits the shan. It seems to me that the ideal way to cover this would be to skip logging on certain classes of Errors (NotAuthorizedError and so on), but maintain logs for all others. I really want to know why things aren't working when my database fails to connect, my resolver logic is flawed, or a third-party package misbehaves. |
@marktani if you still facing this problem you need to add const options = {
port: 8080,
endpoint: "/graphql",
subscriptions: "/subscriptions",
playground: "/playground",
formatError(err: any): any {
return err.message;
},
debug: false // this would prevent logs
};
server.start(options, () => {
console.log("server started!");
}); |
@samuela I had the some problem, and the following did the job for me: import {
isInstance as isApolloErrorInstance,
formatError as formatApolloError,
} from 'apollo-errors'
export default function formatError(error) {
const { originalError } = error
// Skip logging Apollo controlled errors
if (isApolloErrorInstance(originalError)) {
// Maybe do stuff with apollo error
return formatApolloError(error)
}
// Finally, log uncontrolled errors
console.error(error)
return error
} I assume all apollo errors (from |
Due to inactivity of this issue we have marked it |
bump to unstale? |
Due to inactivity of this issue we have marked it |
bump |
This worked for me. |
I think plugins from Envelop's ecosystem with error masking can be used to solve this issue; |
I don't see how I can call a custom handler with that. I can turn off masking, but how about doing something critically important, like logging the error? Where is the |
You can manage error handling as described in here; |
@steida commented on Mon Feb 26 2018
Maybe I am wrong, but
Seems to be a recommended way how to stop resolver, but then probably this should not be logged.
The text was updated successfully, but these errors were encountered: