Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Report more details about errors in do function #24
Hi! For instance, when you execute a request with wrong graphql arguments it retrieves 400 response, and it is difficult to understand which is the problem. It could be either bad argument name, extra variables non-used or another query mistake. It makes hard/slow to implement queries. Graphiql returns real errors, so the developer can figure out which is his mistake faster. Does it make sense? Thanks, Jorge 2018-07-03 20:24 GMT+02:00 Dmitri Shuralyov <firstname.lastname@example.org>:…
Hi, thanks for the PR. I'd like to understand it better, so we can implement a better solution. Can you tell me under what conditions a non-200 response code is expected from a GraphQL server? How can I reproduce this? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABDM3r6RbsdQ09ljvUTxt9V_2N9PNJgXks5uC7b0gaJpZM4U2dpE> .
-- **-* Jorge Sevilla Cedillo *-**
A graphql server can return a 4xx error. As an HTTP server, if the error is found to be on the client side, it must return a 4xx error.
For instance, the postgraphile project has several 4xx status codes.
There are a few reasons I can't merge this PR yet:
I'll need to think more about how to best handle these issues. If you need custom behavior for your specific use case, I suggest using a modified version of this library until we come up with a satisfactory general solution.
referenced this pull request
Sep 17, 2018
Coming here from #29...
Currently only status code 200 is accepted and this PR doesn't change that so this PR isn't really related to which status codes should be handled.
Agreed, that sounds super useful, but I think the vast majority of users of the library would like the response body text from error responses to be exposed in error messages for error responses and it shouldn't be the case that most users need to write their own transport layer just to get a more descriptive error message.
As above, I think this is orthogonal to this PR since this PR doesn't modify which status codes should be considered errors, but rather includes the response body for whatever status codes we consider to be errors as part of the error message.
I definitely agree with the correctness problems, but those are easy to resolve once there is consensus on the direction of the PR.