Catch errors in metrics

[thadeuk]

I notice that api errors are not counted as errors in Cloudwatch metrics. I tested it also in Epsagon and it shows success even for functions that throw.

I've tried to get an error with the following code, they all return the correct HTTP code and message, but metrics does not catch them.
I have no middleware for errors.

module.exports.handler = async (event, context, callback) => {
  context.callbackWaitsForEmptyEventLoop = false;
  return await api.run(event, context, callback);
};

api.get('/profile/unauthorized', async (req, res) => {
  return res.error(401, 'unauthorized');
});

api.get('/profile/error', async (req, res) => {
  throw new Error('any error');
});

api.get('/profile/error500', async (req, res) => {
  return res.error(500, 'explicit error 500');
});

[stawecki]

@thadeuk Lambda API catches thrown errors and returns them as a "custom response" with an HTTP 500 status code, instead of crashing the lambda. There are drawbacks to letting your lambda fail for most of these errors. Check out my response to a similar issue here: #171 (comment)

Let me know, if you have any suggestions or other concerns.

[thadeuk]

@stawecki I was using your method 3 (a), I've added a throw in middleware error function. I was trying to get the error as a 500 HTTP code with the throw message in it, instead of a generic message, but it seems I have to deal with it in another way. Anyway, thanks for sharing your response.

[stawecki]

@thadeuk I haven't found any way so far and it doesn't seem like there is. If you look at AWS docs - Handle Lambda errors in API Gateway it states:

There are two types of errors that Lambda can return: standard errors and custom errors. In your API, you must handle these differently.
With the Lambda proxy integration, Lambda is required to return an output of the following format:
{"isBase64Encoded" : "boolean", "statusCode": "number", "headers": { ... }, "body": "JSON string" }

Also when editing the API in AWS panel, the "standard error" configuration found in "integration response" is disabled for Lambda proxy, so it seems returning a custom error inside a successful lambda execution is the only way to avoid the generic 502 (when using Lambda proxy, which Lambda API relies on). Since this is the only way API Gateway expects the lambda to respond, it makes sense that on failure it doesn't pass any further information to the client.
That said, I still think it's ok to fail your lambda for errors that indicate that it's actually broken. The client doesn't need detailed information about such failure, that's between you and CloudWatch. For everything else, Lambda Insights is a good investment as you can incrementally improve observability of your API by monitoring specific parameters and different types of errors.