Errors Outside Lambda Functions

We’ve covered debugging errors in our code and unexpected errors in Lambda functions. Now let’s look at how to debug errors that happen outside our Lambda functions.

Initialization Errors

Lambda functions could fail not because of an error inside your handler code, but because of an error outside it. In this case, your Lambda function won’t be invoked. Let’s add some faulty code outside our handler function.

Replace our get.js with the following.

import handler from "./libs/handler-lib";
import dynamoDb from "./libs/dynamodb-lib";

// Some faulty code
dynamoDb.notExist();

export const main = handler(async (event, context) => {
  const params = {
    TableName: process.env.tableName,
    // 'Key' defines the partition key and sort key of the item to be retrieved
    // - 'userId': Identity Pool identity id of the authenticated user
    // - 'noteId': path parameter
    Key: {
      userId: event.requestContext.identity.cognitoIdentityId,
      noteId: event.pathParameters.id
    }
  };

  const result = await dynamoDb.get(params);
  if ( ! result.Item) {
    throw new Error("Item not found.");
  }

  // Return the retrieved item
  return result.Item;
});

Commit this code.

$ git add .
$ git commit -m "Adding an init error"
$ git push

Head over to your Seed dashboard, and deploy it.

Now if you select a note in your notes app, you’ll notice that it fails with an error.

You should see an error in Sentry. And if you head over to the Lambda logs in Seed.

You’ll notice that 3 rows have been printed out in the logs. This is because the Lambda runtime prints out the error message multiple times. Note that, only one of them has memory and duration information available. Click on the complete request to expand it.

You should also see an exception TypeError: dynamodb_lib.notExist is not a function, along with the stack trace. This exception is printed out by the Lambda runtime and not by our debug handler. This is because the Lambda function has not been executed. Also note the message at the bottom Unknown application error occurred.

Handler Function Errors

Another error that can happen outside a Lambda function is when the handler has been misnamed.

Replace our get.js with the following.

import handler from "./libs/handler-lib";
import * as dynamoDbLib from "./libs/dynamodb-lib";

// Wrong handler function name
export const main2 = handler(async (event, context) => {
  const params = {
    TableName: process.env.tableName,
    // 'Key' defines the partition key and sort key of the item to be retrieved
    // - 'userId': Identity Pool identity id of the authenticated user
    // - 'noteId': path parameter
    Key: {
      userId: event.requestContext.identity.cognitoIdentityId,
      noteId: event.pathParameters.id
    }
  };

  const result = await dynamoDbLib.call("get", params);
  if ( ! result.Item) {
    throw new Error("Item not found.");
  }

  // Return the retrieved item
  return result.Item;
});

Let’s commit this.

$ git add .
$ git commit -m "Adding a handler error"
$ git push

Head over to your Seed dashboard and deploy it. Then, in your notes app, try and load a note. It should fail with an error alert.

Just as before, you’ll see the error in Sentry. Head over to the Lambda logs in Seed.

Again, there seem to be 3 rows printed out in the logs.

Click on the complete request to expand.

You should see an exception Runtime.HandlerNotFound, along with the stack trace. Also, note the message at the bottom Unknown application error occurred.

And that about covers the main Lambda function errors. So the next time you see one of the above error messages, you’ll know what’s going on.

Rollback the Changes

Let’s revert all the faulty code that we created.

$ git checkout master
$ git branch -D debug

And rollback the prod build in Seed. Click on Activity in the Seed dashboard.

Then click on prod over on the right. This shows us all the deployments made to our prod stage.

Scroll down to the last deployment from the master branch, past all the ones made from the debug branch. Hit Rollback.

This will rollback our app to the state it was in before we deployed all of our faulty code.

Now let’s move on to debugging API Gateway errors.