Serverless SDK modifies error handling and Cloudwatch logs

Serverless Framework
1

Provider: AWS
Runtime: NodeJS 12.x

I’m using Typescript, so using the serverless-plugin-typescript plugin.

I have Serverless Dashboard setup for monitoring.

Before using Serverless to deploy my functions, when an error was thrown by my handler functions, the error would result in an Invocation error and would appear in CloudWatch logs as :
ERROR Invoke Error { … my custom error … }

Now, when an error is thrown, the final logs of the failing request in Lambda looks like :
ERROR Invoke Error
{
“errorType”: “TypeError”,
“errorMessage”: “The first argument must be of type string or an instance of Buffer, ArrayBuffer, or Array or an Array-like Object. Received an instance of InternalServerErrorException”,
“code”: “ERR_INVALID_ARG_TYPE”,
“stack”: [
“TypeError [ERR_INVALID_ARG_TYPE] [ERR_INVALID_ARG_TYPE]: The first argument must be of type string or an instance of Buffer, ArrayBuffer, or Array or an Array-like Object. Received an instance of InternalServerErrorException”,
" at Function.from (buffer.js:327:9)",
" at e.exports.error (/var/task/serverless_sdk/index.js:9:140585)",
" at _ (/var/task/serverless_sdk/index.js:9:135767)",
" at /var/task/serverless_sdk/index.js:9:137263",
" at new Promise ()",
" at /var/task/serverless_sdk/index.js:9:137248",
" at processTicksAndRejections (internal/process/task_queues.js:97:5)"
]
}

InternalServerErrorException being the class of the custom error object that I want to throw (actually it’s from the NestJS framework but anyway).

I looks like the serverless sdk is trying to catch this error and do something with it before throwing it again, but some sort of serialization fails and thus the Invocation error is related to this error instead of my actual error.
It turns out to be pretty difficult to have info about what is happening under the hood with Serverless SDK and what it is trying to do.
Can someone explain this to me please ? :slight_smile:

2

Check this tutorial out: https://www.serverless.com/blog/monitor-and-debug-all-serverless-errors

Basically you must use context.captureError(error) instead of throw error in your catch block

3

Using context.captureError(error) with an async handler results in the warning below.

WARNING: Callback/response already delivered.  Did your function invoke the callback and also return a promise? For more details, see: https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-handler.html

serverless_sdk should properly and transparently handles uncaught errors instead of shifting an unnecessary burden on users to catch everything.

The fact that the Buffer constructor is really old, and serverless_sdk is closed source makes it really uneasy.

4

Basically you must use context.captureError(error) instead of throw error in your catch block

But I still want to make my lambda fail (because I have lambda - SQS integration and I want the SQS message to be retried for instance), so how do I do this without throwing the error ?