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
Is your feature request related to a problem? Please describe.
Currently, if a client submits a query that is malformatted in any way (I.E. is unparsable), then an error is logged. However, the issue came from the client, not the server itself. For my particular purposes, I don't want to see these logged as errors since there is nothing that I can do about the fact that a client has sent my server a bad request.
Describe the solution you'd like
It would be helpful if we had the option to log such errors as warnings instead of always as errors.
Describe alternatives you've considered
Another option could be to throw a custom error to wrap the root cause so that one could easily know what exception to catch via an exception handler and determination of error logging could be processed manually from there.
It might also make sense for exceptions like a JsonParseException to cause a 400 HTTP response and other exceptions like those pertaining to failed attempts at parsing the query due to invalid syntax (but where the JSON parses correctly) would be able to be handled by the server developer or have a mechanism to change the log level of those specific types of exceptions.
Additional context
I've also seen the logging occur when the JSON is valid, but the query itself cannot be parsed because of invalid syntax as well as when the request body is invalid JSON or in an invalid shape. Here is an example JsonParseException that I'm seeing logged, it is occurring because the client didn't send correctly shaped json:
com.fasterxml.jackson.core.JsonParseException: Unrecognized token 'query': was expecting (JSON String, Number, Array, Object or token 'null', 'true' or 'false')
at [Source: (String)"query MyQuery { myProps: props(criteria: { ids: [ "..." ] }) { id value date type }"; line: 1, column: 6]
at com.fasterxml.jackson.core.JsonParser._constructError(JsonParser.java:2391)
at com.fasterxml.jackson.core.base.ParserMinimalBase._reportError(ParserMinimalBase.java:745)
at com.fasterxml.jackson.core.json.ReaderBasedJsonParser._reportInvalidToken(ReaderBasedJsonParser.java:2961)
at com.fasterxml.jackson.core.json.ReaderBasedJsonParser._handleOddValue(ReaderBasedJsonParser.java:2002)
at com.fasterxml.jackson.core.json.ReaderBasedJsonParser.nextToken(ReaderBasedJsonParser.java:802)
at com.fasterxml.jackson.databind.ObjectReader._initForReading(ObjectReader.java:356)
at com.fasterxml.jackson.databind.ObjectReader._bindAndClose(ObjectReader.java:2041)
at com.fasterxml.jackson.databind.ObjectReader.readValue(ObjectReader.java:1492)
at graphql.kickstart.execution.GraphQLObjectMapper.readGraphQLRequest(GraphQLObjectMapper.java:77)
at graphql.kickstart.servlet.GraphQLPostInvocationInputParser.getGraphQLInvocationInput(GraphQLPostInvocationInputParser.java:36)
at graphql.kickstart.servlet.HttpRequestHandlerImpl.handle(HttpRequestHandlerImpl.java:38)
at graphql.kickstart.servlet.AbstractGraphQLHttpServlet.doRequest(AbstractGraphQLHttpServlet.java:82)
at graphql.kickstart.servlet.AbstractGraphQLHttpServlet.doPost(AbstractGraphQLHttpServlet.java:74)
...
The text was updated successfully, but these errors were encountered:
bsara
changed the title
Allow unparsable query to be logged as a warning instead of an error
Allow unparsable query to be logged as a warning instead of an error or handled by server developer
Apr 1, 2022
bsara
changed the title
Allow unparsable query to be logged as a warning instead of an error or handled by server developer
Allow unparsable query to be logged as a warning instead of an error or allow exception to be handled by server developer
Apr 1, 2022
bsara
changed the title
Allow unparsable query to be logged as a warning instead of an error or allow exception to be handled by server developer
Allow unparseable query to be logged as a warning instead of an error or allow exception to be handled by server developer
Apr 1, 2022
Is your feature request related to a problem? Please describe.
Currently, if a client submits a query that is malformatted in any way (I.E. is unparsable), then an error is logged. However, the issue came from the client, not the server itself. For my particular purposes, I don't want to see these logged as errors since there is nothing that I can do about the fact that a client has sent my server a bad request.
Describe the solution you'd like
It would be helpful if we had the option to log such errors as warnings instead of always as errors.
Describe alternatives you've considered
Another option could be to throw a custom error to wrap the root cause so that one could easily know what exception to catch via an exception handler and determination of error logging could be processed manually from there.
It might also make sense for exceptions like a
JsonParseException
to cause a 400 HTTP response and other exceptions like those pertaining to failed attempts at parsing the query due to invalid syntax (but where the JSON parses correctly) would be able to be handled by the server developer or have a mechanism to change the log level of those specific types of exceptions.Additional context
I've also seen the logging occur when the JSON is valid, but the query itself cannot be parsed because of invalid syntax as well as when the request body is invalid JSON or in an invalid shape. Here is an example JsonParseException that I'm seeing logged, it is occurring because the client didn't send correctly shaped json:
The text was updated successfully, but these errors were encountered: