-
Notifications
You must be signed in to change notification settings - Fork 249
log.info in defaultErrorFormatter #983
-
I was wondering what the reasoning was for the following change (a115d81#diff-0af7067b49efcaf7dae9a3707f2e79638b336e72780d2b834e007f80ef9a5fa0):
Is it because a GraphQL error could represent anything from a server error to a client validation error and log.info is the lowest common denominator log level wise?
Beta Was this translation helpful? Give feedback.
All reactions
Because an error in GraphQL will return a 200 anyway. It's an expected response and not an error situation for the server.
Replies: 1 comment 2 replies
-
Because an error in GraphQL will return a 200 anyway. It's an expected response and not an error situation for the server.
Beta Was this translation helpful? Give feedback.
All reactions
-
Hmm out of curiosity, would the best thing to do be to trace any server errors that might still result in a 200 (eg some connection not resolving correctly) separately from w/e the defaultErrorFormatter is doing in eg. the onResolution hook and assume that all logging from the defaultErrorFormatter is informational, while the developer is responsible for separately tracing actual exceptions?
Beta Was this translation helpful? Give feedback.
All reactions
-
if there are specicific class of errors you want to treat differentely, you can go ahead and implement your own formatter. I actually recommend to.
Beta Was this translation helpful? Give feedback.