You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using Graphene with graphql-core 2.0, I was able to write middleware that would catch errors:
classErrorHandlerMiddleware():
defresolve(self, next, root, info, **args):
try:
returnnext(root, info, **args)
exceptExceptionasex:
# log error with Sentryinfo.context.sentry.captureException()
# Return a generic rejectionreturnGraphQLError("System error. Please try again later.")
It wasn't perfect. Both the original exception and GraphQLError would wind up appearing as Sentry issues, but it'd at least get reported and send back a generic error to the user.
I've since bumped graphql-core to 2.1 to take advantage of the logging improvements, but I'm not clear on how the above could be achieved in 2.1? With the latest version, the original exception winds up in the message field of the response... potentially exposing sensitive info, like SQL errors, etc.
Could you please post an example in the README of how one might write middleware or use the new logging set-up to capture errors and replace the response with a generic message? I think that would be a really common use-case that many would find useful.
The text was updated successfully, but these errors were encountered:
FWIW, this is what I wound up doing. Can anyone see an issue with this approach?
deferror_handler(ex):
print("original exception", ex) # replace this with third-party loggingraiseException("System error") # some error message to show to usersclassErrorMiddleware:
defresolve(next, root, info, **args):
res=next(root, info, **args)
returnres.then(None, error_handler)
With the print line in the error handler being replaced with Sentry logging, and the new exception being raised to mask the original (hiding sensitive details like SQL queries, etc)
It still logs out graphql.error.located_error.GraphQLLocatedError: System error to stderr but setting the main logger to silence those should take care of it.
I'll leave this open to get consensus on this approach.
Using Graphene with graphql-core 2.0, I was able to write middleware that would catch errors:
It wasn't perfect. Both the original exception and GraphQLError would wind up appearing as Sentry issues, but it'd at least get reported and send back a generic error to the user.
I've since bumped graphql-core to 2.1 to take advantage of the logging improvements, but I'm not clear on how the above could be achieved in 2.1? With the latest version, the original exception winds up in the
message
field of the response... potentially exposing sensitive info, like SQL errors, etc.Could you please post an example in the README of how one might write middleware or use the new logging set-up to capture errors and replace the response with a generic message? I think that would be a really common use-case that many would find useful.
The text was updated successfully, but these errors were encountered: