Inconsistent errors.extensions response for invalid query

[akbindal]

For invalid query, let's say for requesting the field not defined in the schema leads to following error response

{
    "errors": [
        {
            "message": " ...... ",
            "locations": [
                {
                    "line": 14,
                    "column": 9
                }
            ],
            "extensions": {
                "classification": "ValidationError"
            }
        }
    ]
}

I'd expect more consistent error response from extension where DGS has errorType in the extension.

{
    "errors": [
        {
            "message": " ...... ",
            "locations": [
                {
                    "line": 14,
                    "column": 9
                }
            ],
            "extensions": {
                "errorType": "BAD_REQUEST"
            }
        }
    ]
}

Is it expected behavior?

[srinivasankavitha]

Yes, this is expected behavior as that error indicates a schema validation error thrown by `graphql-java`. The DGS framework simply wraps that particular error in a DataFetcherResult and returns it.

…

On Wed, Feb 9, 2022 at 6:47 AM Ashish Bindal ***@***.***> wrote: For invalid query, let's say for requesting the field not defined in the schema leads to following error response { "errors": [ { "message": " ...... ", "locations": [ { "line": 14, "column": 9 } ], "extensions": { "classification": "ValidationError" } } ] } I'd expect more consistent error response from extension where DGS has errorType in the extension. { "errors": [ { "message": " ...... ", "locations": [ { "line": 14, "column": 9 } ], "extensions": { "errorType": "BAD_REQUEST" } } ] } Is it expected behavior? — Reply to this email directly, view it on GitHub <#869>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ5JPXPB5TVPEHLMEZQFFHLU2J467ANCNFSM5N5WXKLA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[akbindal]

ok @srinivasankavitha

IMO API implemented using DGS should throw the consistent error response upto the level of extensions irrespective of origin of error.

DataFetcherExceptionHandler can't catch such errors. If I try to intercept them using GraphQLErrorHandler, it breaks the functionality due to dependency on the graphql-kickstart-library with following response:
graphql.servlet.HttpRequestHandlerImpl : Bad GET request: path was not "/schema.json" or no query variable named "query" given

Is there a way where I can gracefully wrap/modify errors originated by graphql-java (graphql-engine)?

[srinivasankavitha]

You can add your own exception handler that delegates to the default. There you can wrap the errors the way you prefer: https://netflix.github.io/dgs/error-handling/#mapping-custom-exceptions

…

On Thu, Feb 10, 2022 at 1:38 AM Ashish Bindal ***@***.***> wrote: ok @srinivasankavitha <https://github.com/srinivasankavitha> IMO API implemented using DGS should throw the consistent error response upto the level of extensions irrespective of origin of error. DataFetcherExceptionHandler can't catch such errors. If I try to intercept them using GraphQLErrorHandler, it breaks the functionality due to dependency on the graphql-kickstart-library with following response: graphql.servlet.HttpRequestHandlerImpl : Bad GET request: path was not "/schema.json" or no query variable named "query" given Is there a way where I can gracefully wrap/modify errors originated by graphql-java (graphql-engine)? — Reply to this email directly, view it on GitHub <#869 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ5JPXPAQNUAIHOXLTDIXCDU2OBRXANCNFSM5N5WXKLA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[akbindal]

That doesn't work, DataFetcherExceptionHandler doesn't catch the errors thrown by graphql-java. As I wrote earlier these errors can be wrapped by GraphQLErrorHandler but then it breaks the graphQL servlet functionality. I would appreciate it if you have any other pointers to resolve this issue. On Thu, Feb 10, 2022, 19:43 Kavitha Srinivasan ***@***.***> wrote:

…

You can add your own exception handler that delegates to the default. There you can wrap the errors the way you prefer: https://netflix.github.io/dgs/error-handling/#mapping-custom-exceptions On Thu, Feb 10, 2022 at 1:38 AM Ashish Bindal ***@***.***> wrote: > ok @srinivasankavitha <https://github.com/srinivasankavitha> > > IMO API implemented using DGS should throw the consistent error response > upto the level of extensions irrespective of origin of error. > > DataFetcherExceptionHandler can't catch such errors. If I try to > intercept them using GraphQLErrorHandler, it breaks the functionality due > to dependency on the graphql-kickstart-library with following response: > graphql.servlet.HttpRequestHandlerImpl : Bad GET request: path was not > "/schema.json" or no query variable named "query" given > > Is there a way where I can gracefully wrap/modify errors originated by > graphql-java (graphql-engine)? > > — > Reply to this email directly, view it on GitHub > < #869 (reply in thread) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AJ5JPXPAQNUAIHOXLTDIXCDU2OBRXANCNFSM5N5WXKLA > > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#869 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFIM4LWCNFXZTZOIW5WAXDU2QBLZANCNFSM5N5WXKLA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mayankagrawalcts]

We also similar type of requirement however not getting any help