{"message": "Internal server error"} on API Gateway responses with 1.5

Serverless Framework
1

I just want to return the error object. I was hoping callback(error) would work but it doesn’t. All I get is {“message”: “Internal server error”} via the API gateway. My error object looks good to go:

{ [MessageRejected: Email address is not verified. The following identities failed the check in region US-WEST-2: john@example.com]
  message: 'Email address is not verified. The following identities failed the check in region US-WEST-2: john@example.com',
  code: 'MessageRejected',
  time: Sat Jan 14 2017 06:11:18 GMT+0000 (UTC),
  requestId: '42f24198-da20-11e6-adbb-b3d5ae331505',
  statusCode: 400,
  retryable: false,
  retryDelay: 92.85304674413055 }

I played around with Pass through behaviours and that didn’t work.

I did also notice template: $input.path("$.errorMessage") # JSON return object but that example didn’t make any sense to me.

What am I missing exactly from https://s.natalian.org/2017-01-14/serverless.yml ?

2

If you want to actually return the error to the end (HTTP) user, then you don’t want to pass the error to the callback - that’s telling Lambda and API GW that the function had an error (which is why it’s telling the user 500).

It sounds like you want a successful HTTP request/response, with the error details as the payload.
So you should be using callback(null, error) instead of callback(error).

Not sure if I’m explaining clearly, but I’m pretty sure that’s what you’re after.

1 Like
3

Thanks for the reply!

callback(null, error) doesn’t work for me (HTTP/1.1 502 Bad Gateway), despite the error object having a response code set in the object IIUC!!

What did end up working was:

callback(null, { statusCode: 400, body: JSON.stringify(error) });

Still don’t understand… must be a bug or inconsistency I assume with the way the error object is treated.

4

Ah, sorry about that. I was forgetting the new Lambda proxy response types - I still often forget to stringify the payload :confounded:.

Glad you sorted it out.

1 Like
5

What you’re sending back in the callback in the situation of a basic Lambda Proxy is the actual response object. You’ve got to set the statusCode, headers, and body as shown in the Serverless documentation.

statusCode should be a number
headers is an Object with the key-value pairs as your header key-value pairs
body is the response body, which needs to be JSON.stringify-ed by you if it’s a JSON Doc

6

When you hit an internal server error it usually means some parts of your web server is not configured correctly or the application is trying to do something and the server is failing to carry out the request due to a conflict or restriction. This error can only be resolved by fixes to the Web server software . It is up to the administrators of the Web server site to locate and analyse the logs which should give further information about the error.

7

Same here - banging my head for hours - it is still raw from documentation and implementation perspective so not synchronized… I’m wasting my time here :frowning:

1 Like
8

I relized that the problem was with
serverless deploy -f function_name I just used serverless deploy -v
and it is working now

const response = {
statusCode: 200,
body: JSON.stringify({
message: Data
}),
};

callback(null, response);