log.info in defaultErrorFormatter

[PieterJanVdb]

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?

[mcollina]

Because an error in GraphQL will return a 200 anyway. It's an expected response and not an error situation for the server.

[PieterJanVdb]

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?

[mcollina]

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.