Surfacing HTTP Status Codes of Queries

Issue: If a query returns a HTTP status code other than 200, express-graphql still returns 200, with the error placed in an array assigned to the errors property.

This can cause problems with caching. When error status codes are not set and a 200 is sent instead, the error or incomplete data will be cached.

Example: You are hosting an online store. Someone views a product. The product details query returns an HTTP error, but the reviews query and recommendations query do not. That product’s incomplete data is now cached due to the 200 status code, instead of surfacing the product details query’s status code.

Proposed Solution: I think the simplest solution would be creating a new option handleErrors, a function that receives the errors array and the response object on line 247 in src/index.js. If option was set, invoke it, otherwise do nothing. This will allow developers to access the errors and decide how they want to handle them or modify the response before being sent.

I wanted to gauge interest and feedback on this before I looked to submit a pull request. Please let me know if you would accept this PR and this proposed solution.

[iki]

Actually, GraphQL specifies passing errors via errors field in the response and not using application transport protocol level, which may or may not be HTTP.

This concept can be simplified as always send 200 with graphql json response, or 500 if server blows up and is shared for example by facebook relay, graphcool, apollo-server, and graphene on server side, and expected for example by apollo-client on client-side.

Sending other error codes with graphql json response may result in graphql clients assuming server error and not trying to parse json in body, so the passed errors field is lost and error is replaced with generic http status error. This happens e.g. with apollo-client.

It would be nice to either unify on single concept, or make it configurable.

[tim-steele]

@allardhoeve - We are using Apollo, and we use formatError. It a nutshell, it is like this:

function formatError(error, res) {
  res.status(error.status);
  const formattedError = myFormatFunction(error);

  return formattedError;
}

@moekhalil agree the multiple responses make it difficult. It isn’t a “simple” problem to solve. We generally default to 500 for server problem, 400 for client problem. Ultimately, when everything is a 200 it can create problems with caching layers and server monitoring. Also, for Apollo, if you return an error it doesn’t cache it locally, and triggers the catch() on mutations vs. having to data check to validate responses. My $.02.