fix(http-error-handler): non http errors will always be handled

[qoomon]

http-error-handler currently does not handle non http errors if fallbackMessage is not set.

This PR will handled all non http errors as 'Internal Server Error' even if no fallback message is configured.
I think this is a more expected behaviour of an error handler.

[willfarrell]

Thanks for putting a PR together. This proposes a breaking change, so would need to go into v5 if approved. This logic is in place to allow handling http and internal errors in separate middlewares. Additionally, this is in place to not have the default message be in english.

Let me take some time to reflect on this. I agree that needing to always set it for the most common use case can get annoying depending on how you structure your code.

[qoomon]

I think in case of a http lambda, the http error handler is or should always be the last one. Every error handling can be done before, however if an unexpected error reaches the http error handler it should response with an 500 instead of just doing nothing.

[willfarrell]

After some reflection and some more research, I think we can merge this into the v5 branch. I'll can update the tests, docs and change log. Thanks for putting this together.

[grant-d]

[edit] Moved into its own issue

We have a middy APG (Api Gateway) / lambda stack that has been working great for a couple of years.
I upgraded the stack a couple of days ago, from @middy 4 -> 5
In doing so, the Custom/Lambda-Authorizer in APG does not handle Unauthorized properly anymore.

I realize that 5 is a breaking change, but I am not sure what the guidance is. Everything works fine in other lambdas, but APG has specific patterns and expectations for lambda authorizer 401 errors, and that pattern now seems broken.

The internals of APG expect to get a message shaped like this { message: "Unauthorized" } (which worked in v4) but I am guessing v5 now sends { body: ..., statusCode: ...}

Please advise.

BEFORE (using middy@4):

  // import @[email protected]
  if { userIsNotAuthorized } throw Error('Unauthorized') // AWS prescribes this EXACT pattern with Custom Authorizers
  // callback("Unauthorized") // ... or this

  middy.use(httpErrorHandler()) // etc

  // APG CloudWatch logs (everything looks GOOD)
  Gateway response type: UNAUTHORIZED with status code: 401
  Gateway response body: 
  {
      "message": "Unauthorized"
  }

  // Postman response
  {
      "message": "Unauthorized"
  }

AFTER (upgrade to middy@5):

  // import @[email protected] // This is the only change
  if { userIsNotAuthorized } throw Error('Unauthorized')
  // I also tried `throw createError.Unauthorized()` per docs, but similar result to below

  middy.use(httpErrorHandler())

  // APG CloudWatch logs (BAD)
  Authorizer result body before parsing:
  {
      "statusCode": 500,
      "headers": {} // Note the lack of a `message` property, which by default APG expects for 4XX responses/templates
  }
  Execution failed due to configuration error: Invalid JSON in response: Unrecognized field "statusCode" , not marked as ignorable

  // Postman response
  {
      "message": null
  }

AFTER (removed httpErrorHandler):

  // import @[email protected]
  if { userIsNotAuthenticated } throw Error('Unauthenticated')

  // middy.use(httpErrorHandler()) // Removed this handler

  // APG CloudWatch logs (kinda GOOD)
  // Gateway response type: UNAUTHORIZED with status code: 401 // Weird, this line is missing in logs now
  Gateway response body: 
  {
      "message": "Unauthorized"
  }

  // Postman response
  {
      "message": "Unauthorized"
  }

Originally posted by @grant-d in #1117 (comment)