Logic Errors in Lambda Functions

Now that we’ve setup error logging for our API, we are ready to go over the workflow for debugging the various types of errors we’ll run into.

First up, are errors that can happen in our Lambda function code. Now we all know that we almost never make mistakes in our code. However, it’s still worth going over this very “unlikely” scenario.

Create a New Branch

Let’s start by creating a new branch that we’ll use while working through the following examples.

In the project root for your backend repo, run the following:

$ git checkout -b debug

Push Some Faulty Code

Let’s trigger an error in get.js by commenting out the noteId field in the DynamoDB call’s Key definition. This will cause the DynamoDB call to fail and in turn cause the Lambda function to fail.

Replace get.js with the following.

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

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 dynamoD.get(params);
  if ( ! result.Item) {
    throw new Error("Item not found.");
  }
  
  // Return the retrieved item
  return result.Item;
});

Note the line that we’ve commented out.

Let’s commit our changes.

$ git add .
$ git commit -m "Adding some faulty code"
$ git push --set-upstream origin debug

Deploy the Faulty Code

Head over to your Seed dashboard and select the prod stage in the pipeline and hit Deploy.

Select the debug branch from the dropdown and hit Deploy.

This will deploy our faulty code to production.

Head over on to your notes app, and select a note. You’ll notice the page fails to load with an error alert.

Debug Logic Errors

To start with, you should get an email from Sentry about this error. Go to Sentry and you should see the error showing at the top. Select the error.

You’ll see that our frontend error handler is logging the API endpoint that failed. Copy the URL.

Then we’ll search for the Lambda logs for that endpoint on Seed. Click View Lambda logs.

Paste the URL and select the GET method row.

By default, the logs page shows you the request from a few minutes ago, and it automatically waits for any new requests. You should see the failed request in the logs if it just happened. If it did not happen in the last few minutes, select the time field, and copy and paste the time from Sentry. Ensure to add UTC at the end of the time because Seed assumes local time, if it’s entered without a timezone.

Note that we are using Seed to look up the Lambda logs for your Serverless app. However, you can just use CloudWatch logs directly as well. It’s a little harder to find your logs but all the logged info is available there. We have a detailed extra-credit chapter on this.

You should see a failed request highlighted in red. Multiple failed requests might show up if you tried to load the note multiple times. Click to expand the request.

In the error details, you’ll see a debug log of all the actions. Starting with the AWS DynamoDB call. You can see all the parameters sent in the call.

If you scroll down, you should see the ValidationException error that was caught by our handler.

The message The provided key element does not match the schema, says that there is something wrong with the Key that we passed in. Our debug messages helped guide us to the source of the problem!

Next let’s look at how we can debug unexpected errors in our Lambda functions.