apollo-server-express gives 500 error but does not show description

[frederikhors]

I'm trying apollo-server-express.

What I don't find in docs and don't understand is how to show description of a 500 error.

Example:

const serverApollo = new ApolloServer({
  typeDefs,
  resolvers,
  context: ({ req }) => {
    // req.user is undefined here
    console.log('*req', req) // -> no req.user present!
    return {
      currentUser: { id: req.user.id }
    }
  }
})

Correctly express gives me a 500 error. Good.

But how to show the error description?

I have this code in app.js:

...
serverApollo.applyMiddleware({ app })

// -> It doesn't call anything below, why?
// This code is a standard Express template for error handling: http://expressjs.com/en/guide/error-handling.html
app.use(function (req, res, next) {
  next(createError(404))
})

app.use(function (err, req, res, next) {
  console.log('err:', err)
  res.locals.message = err.message
  res.locals.error = req.app.get('env') === 'development' ? err : {}
  res.status(err.status || 500)
  res.render('error')
})

Is there some logging level error in Apollo?

[abernix]

The above error should surface just fine within the errors property of the GraphQLResponse. In "production" (that is, when process.env.NODE_ENV is set to production), the actual error message will be redacted and output as INTERNAL_SERVER_ERROR, but during development you should be able to see the full error.

If you'd like to change the behavior to ensure that the full error is also shown in production, you can set debug: true on the ApolloServer constructor. If you'd like to output the full error elsewhere, consider using the didEncounterErrors life-cycle method (#2719) or outputting the error to a logger within formatError.

If anyone continues to struggle with this, please feel free to open a new issue and include a runnable reproduction demonstrating the problem.

Unrelated to the original post, if anyone is upset with the state of our documentation or error handling, feel free to open issues targeting specific areas needing improvement with concrete suggestions of what needs improvement. Otherwise, it's unlikely that the documentation or errors will merely "improve".