HTTP codes in graphql responses using the dynamic client

[maag03]

We're using the smallrye graphql dynamic client and when the graphql server responds with HTTP 401 we just get an empty Response.
Is it possible to get hold of the HTTP status code somehow ?
What is the best way to handle this situation ?

This is how the 401 reply from the graphql server looks like:
{
"fault": {
"code": 900709,
"message": "Invalid Credentials",
"description": "Access failure for API: /xxxxxx/1.0, version: 1.0 status: (900709) - Invalid Credentials. Make sure you have given the correct access token"
}
}

[quarkus-bot[bot]]

/cc @jmartisk, @phillip-kruger

[jmartisk]

Hi,
the client assumes HTTP code 200 if there's a GraphQL response present, even if it contains an error (meaning there's something in the errors field). We've been following the graphql-over-http spec: https://graphql.org/learn/serving-over-http/ for both the client and server libraries, and it does not seem to specify anything about HTTP response codes. So we assume it's always 200 unless the error happens somewhere higher up the stack, rather than in the GraphQL layer. I think that's correct, maybe @phillip-kruger can comment on this. The server-side library (smallrye-graphql Quarkus extension) does it this way right now.

But yeah, if you're connecting to external services which actually do return different codes, then it might be useful to add that (option to find out the code) into the client. It's not possible now (the status code is ignored) so that would have to be implemented.

[maag03]

Thanks for reply Jan!

[gsmet]

FWIW, I also got hit by that and ended up checking the errors myself while I would have expected getting an exception if it's a plain big error.

[phillip-kruger]

I think the typesafe will translate to an exception. We can probably do the same with dynamic . @jmartisk ?

[jmartisk]

Typesafe client asserts that the code is always 200 (for error and non-error responses), otherwise it throws an exception that contains the raw body (as a string). Which seems incorrect, because as we see, even if the status isn't 200, there could be an error that can be parsed into a GraphQLError object and returned to the application...

Maybe we shouldn't rely much on the status code, but rather check whether there are GraphQL errors present in the response?! If yes, then translate that normally into GraphQLError. Only if there's no GraphQL error AND the status code isn't 200, then throw an exception instead of handling the response normally.

And the dynamic client could receive a way to find out the status code programmatically, it might be useful in cases like the one that the reporter described.

[jmartisk]

There's a discussion about proper error handling in smallrye/smallrye-graphql#1402 - feedback welcome