Parsing [XXX] in error messages, to match serverless 1.0

[marccampbell]

This fixes #108

There are a few ways this could be accomplished. Is this an acceptable solution?

This isn't a significant change, but when an error message is being returned from a serverless handler, if there's a "[XXX] Message" in the response, the status code on the response object will be set from this error object.

It makes no attempt to response the different patterns that serverless supports with API Gateway. I feel that this is out of scope of this PR and could be an interesting option by itself.

[leonardoalifraco]

This behavior is only valid for the lambda integration type.

@dherault If you decide to merge this before #131 let me know and I'll make the proper adjustments in my PR.

[dherault]

Hi @marccampbell, thanks a lot for the PR.
Let's wait for the lambda integration feature before merging this one.

[dherault]

@marccampbell Ok I merged the integrations PRs #129 and #131. Can you fix the conflicts please? Extra kudos if you write some tests 👍, thanks

[dherault]

@marccampbell Is this ready? I can merge it today
Also, it('should set the status code to 500 when no [xxx] is present', ...) is it the case on AWS?

[leonardoalifraco]

@dherault @marccampbell I've tested this and I think it is ok.
However, after merging it, we'll need to make a few changes to the change that was before @marccampbell changes in order to match the exact response for errors.

IE:
When the error callback receives an string, we are returning:

{
  "errorMessage": "[504] Fake internal server error.",
  "errorType": "String",
  "stackTrace": null
}

But we should be returning only the errorMessage:

{
  "errorMessage": "[504] Fake internal server error."
}

I'll merge it and then change adapt the string response.

Thanks!

[demetriusnunes]

Thanks guys, super awesome!

[dherault]

Oh right, forgot to say: v3.3.0 ;)