I’ve noticed that the GraphQL endpoint is always returning a http status code OK regardless of token, role permission or query validity. This is probably working as intended but it would be easier to handle unauthorized errors or malformatted queries with the appropriate status codes. Currently I’m handling these errors with a regex pattern on the error message, but this may break if the endpoint ever changes the message content. If this isn’t easy to implement, error extensions with additional metadata would also be useful.
I think this is less of a Fauna issue, than a canonical way of working with GraphQL. See this article about error handling with Sangria/Scala (because that’s my guess to what is running).
Note what it says:
errors thrown during query execution (read: inside the GraphQL resolver methods) are always returned by the GraphQL server as an HTTP response with the status code
That’s not something I think Fauna can change. Most unauthorized errors, for example, are going to come only during query execution, which means during resolvers, which means code
That’s indeed the default behavior in most of the situations. I had forgotten that most of the GraphQL implementations don’t allow you to manipulate the response context that easily. But it should still be possible to implement custom error extensions with additional metadata, no?
Providing an invalid key returns code
200 with error message “Invalid authorization header.” In my opinion I would prefer that to return a
4xx. I also think one could argue that a malformed query (e.g. a spelling typo) should be
The FP enthusiast in me kinda wishes there was a
type field to accompany the error
message, making pattern matching way easier. But then that opens up a huge can of worms as to what those types should be. You could really specific, but then, do you actually want really specific error sent to the client? Or is what you really want better debugging info during dev. I don’t expect it would be trivial to provide separate info for debugging what with only a single endpoint for everything.
@edwjusti Do you think this request can be more narrowly targeted then? Can this Topic be just for rallying around
4xxfor bad authorization header.
400for other bad requests.
500I guess if other stuff blows up? It’s a good sign I haven’t encountered it!
Then a separate Topic to explore how resolver errors can be extended with more/different/better meta data?
Sure, I think it makes sense to focus on the HTTP status codes here. A separate thread can be opened to explore the possibilities of new metadata implemented with standard errors.
fyi (and for other faunas reading this) I did an internal request to see what is possible and to make sure your feedback does not get lost.