You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 20, 2023. It is now read-only.
#736 reverted something the community aligned behind changing, without addressing the concerns of the community. The author of said revert PR seems to be misreading their own link, since the spec seems pretty clear that responses that contain a nulldata property are recommended to contain status code 200, and nowhere does it say these responses must contain 500 which is @acao's claim.
Perhaps as a compromise, there can be a way to opt into (seemingly non spec compliant) behavior of forcing all errors to be 500 errors, however for all intents and purposes, this behavior completely breaks clients error handling behavior as described in detail in #427
diff --git a/node_modules/express-graphql/index.js b/node_modules/express-graphql/index.js
index 3bc78dc..d72a19d 100644
--- a/node_modules/express-graphql/index.js+++ b/node_modules/express-graphql/index.js@@ -174,14 +174,6 @@ function graphqlHTTP(options) {
result = { data: undefined, errors: error.graphqlErrors };
}
}
- // If no data was included in the result, that indicates a runtime query- // error, indicate as such with a generic status code.- // Note: Information about the error itself will still be contained in- // the resulting JSON payload.- // https://graphql.github.io/graphql-spec/#sec-Data- if (response.statusCode === 200 && result.data == null) {- response.statusCode = 500;- }
// Format any encountered errors.
const formattedResult = {
...result,
#736 reverted something the community aligned behind changing, without addressing the concerns of the community. The author of said revert PR seems to be misreading their own link, since the spec seems pretty clear that responses that contain a
null
data
property are recommended to contain status code 200, and nowhere does it say these responses must contain 500 which is @acao's claim.Perhaps as a compromise, there can be a way to opt into (seemingly non spec compliant) behavior of forcing all errors to be 500 errors, however for all intents and purposes, this behavior completely breaks clients error handling behavior as described in detail in #427
This issue body was partially generated by patch-package.
The text was updated successfully, but these errors were encountered: