middy: Improve Http Error messages

I altered the httpErrorHandler to follow the JSON spec http://jsonapi.org/examples/#error-objects-basics.

Should this change get applied across the board? Or should I just use this as my own custom middleware?

Whats the default lambda integration you guys are using? (we typically use lambda-proxy as the serverless framework default)

Here is my altered error handler for nice errors =)

const { HttpError } = require('http-errors')

module.exports = () => ({
  onError: (handler, next) => {
    if (handler.error instanceof HttpError) {
        // as per JSON spec http://jsonapi.org/examples/#error-objects-basics
        handler.response = {
          body: JSON.stringify({
            errors: [{
              status: handler.error.statusCode,
              message: handler.error.message,
              detail: handler.error.details
            }]
        })
      }
      return next()
    }

    return next(handler.error)
  }
})

It looks like:

Before with body: handler.error.message (no json response)

Love this freakin project! Great work 🎉

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 14
Comments: 15 (11 by maintainers)

Most upvoted comments

BTW here’s the middleware I ended up writing: https://github.com/dbartholomae/middy-middleware-json-error-handler

dbartholomae on Feb 10, 2020

In the end is just a matter of specific use cases vs common patterns, guess is better to wait for the community to grow (I am sure it will grow!). Right now I have “middified almost everything in my lambdas”.

Following @theburningmonk advices above I have created a set of custom errors for my libraries (data layer, services), that break the execution chain and are handled by a set of error middlewares.

I love the idea of using httpErrors to manage “handled” exceptions, so I’m catching the incoming custom errors and transforming them into common sense httpErrors in a specific middleware, I keep the traces and messages in “development mode” or just standard messages in production to hide the implementation as suggested.

middy(logic)
  (...) // other middleware
  .use(responseSerializer) // ::after - Yes, I have an approach for that too
  .use(customErrorHandler) // ::onError - Parses custom error types and transform them into httpErrors
  .use(httpJsonApiErrorHandler)  // ::onError - Adapt any httpError to JsonAPI, anything else into 500 generic error

I would be nice to have access to other patterns and use cases from other users (perhaps a gitter channel or is too early?). I would watch the repo and see if I can PR something 😉

jacintoArias on Mar 8, 2018

I came here after dealing myself with the same error pointed out by @DavidWells when implementing my custom error handling middleware. I ended up almost copying his solution to correctly follow the JSON API spec.

At least for the lambda proxy integration, the error response should change the body format or the content header, otherwise the response is not valid…

PS: Awesome work guys! I LOVE this project

jacintoArias on Mar 6, 2018

@DavidWells @jacintoArias Have you tried https://github.com/willfarrell/middy-jsonapi, I’ve been using it for about 2y now without issue.

willfarrell on Jan 5, 2020

As for handling different content types, keep in mind that we might want to consider binary formats as well. What if you always inspect the content-type in the response, and defaults to JSON if it’s not specified, and bundle only JSON handling in middy by default.

You can then later introduce XML, proto-buf and other formats as middleware? (in the case of protobuf, you also have to set the isBase64Encoded to true, for instance)

theburningmonk on Dec 20, 2017