middy-jsonapi treats BadRequest errors from Middy validation as unhandled errors

[kpeters-cbsi]

I have a Typescript Lambda set up like so:

import { APIGatewayProxyHandler } from 'aws-lambda'
import middy from '@middy/core'
import cors from '@middy/http-cors'
import httpJsonBodyParser from '@middy/http-json-body-parser'
import jsonapi from 'middy-jsonapi'
import validator from '@middy/validator'
import httpContentNegotiation from '@middy/http-content-negotiation'

const main: APIGatewayProxyHandler = async (event) => { 
  ...
}

export const handler = middy(main)
  .use(httpJsonBodyParser())
  .use(cors())
  .use(jsonapi({ response }))
  .use(
    httpContentNegotiation({
      availableLanguages: ['en-US'],
      availableMediaTypes: ['application/vnd.api+json'],
    })
  )
  .use(validator({ inputSchema }))

But when I send an invalid payload to it, I get a 500 back instead of a 400. I've traced the error to line 72 of index.js. The error class is BadRequestError, but handler.error instanceof createError.BadRequest evaluates to false. Not sure where to take it from there, otherwise I'd whip up a PR.

[willfarrell]

I'm open to reviewing a PR

[kpeters-cbsi]

You would say that. 🤣 Let me see what I can do.

One thing I notice off the bat is that it doesn't look like validator is using http-errors (link):

      const { createError } = require('@middy/util')
      ...
      const error = createError(400, 'Event object failed validation')

createError is defined in @middy/util

So you might, for example, be able to check for error.status && error.status === 400

[willfarrell]

The createError function within @middy/util is a stripped down version of http-errors to keep the middleware as small as possible. It's the same object, just without all the developer helper features.

[kpeters-cbsi]

Right, but it's not the same object. That's why the check is failing.

[willfarrell]

If that's the case would you like to submit a PR to @middy/util with some additional tests? I can PR review other there :).

[kpeters-cbsi]

No, I think @middy/util is fine. If they want to use a stripped down version of http-errors that's their business. I think the change needs to happen in this codebase.