From Internal Server Error to Success: Debugging AWS Lambda and API Gateway

Building a serverless application is exciting—until you hit a roadblock like the dreaded "Internal Server Error." Recently, I encountered this while creating a simple API with AWS Lambda and API Gateway to process query parameters and return a structured response. This post breaks down my debugging journey, what went wrong, and how I fixed it.

The Problem

My goal was straightforward:

1. Accept transactionId, type, and amount as query parameters.
   


2. Log the parameters and return them in a JSON response.

Here’s the Lambda function I wrote initially:

import json



def lambda_handler(event, context):

    transactionId = event['queryStringParameters']['transactionId']

    transactionType = event['queryStringParameters']['type']

    transactionAmount = event['queryStringParameters']['amount']



    print(f"TransactionId = {transactionId}")

    print(f"TransactionType = {transactionType}")

    print(f"TransactionAmount = {transactionAmount}")



    response = {

        'transactionId': transactionId,

        'type': transactionType,

        'amount': transactionAmount,

        'message': "Hello from lambda land"

    }



    return {

        'statusCode': 200,

        'headers': {

            'Content-Type': 'application/json',

        },

        'body': json.dumps(response)

    }

But when I tested the API through the browser, I kept getting:

• 
  500 Internal Server Error
  


• 
  CORS errors when calling the API from my frontend.

What Went Wrong?

1. Missing Query Parameters:
   
   
   If any query parameter was missing, the code would throw a KeyError. This caused Lambda to fail and returned a generic error message without any details.




2. No Error Handling:
   
   
   There was no mechanism to catch and log errors. This made debugging harder because the API Gateway logs only showed "Internal Server Error."




3. CORS Issues:
   
   
   The response didn’t include Access-Control-Allow-Origin, which is required to enable communication between the frontend and the API Gateway endpoint.

The Fix

I rewrote the Lambda function with robust error handling, validation, and proper CORS configuration.

import json



def lambda_handler(event, context):

    try:

        # Extract query string parameters

        params = event.get('queryStringParameters', {})

        transactionId = params.get('transactionId', 'N/A')

        transactionType = params.get('type', 'N/A')

        transactionAmount = params.get('amount', 'N/A')



        # Validate parameters

        if transactionId == 'N/A' or transactionType == 'N/A' or transactionAmount == 'N/A':

            raise ValueError("Missing required query parameters")



        # Log parameters

        print(f"TransactionId = {transactionId}")

        print(f"TransactionType = {transactionType}")

        print(f"TransactionAmount = {transactionAmount}")



        # Create response

        transactionResponse = {

            'transactionId': transactionId,

            'type': transactionType,

            'amount': transactionAmount,

            'message': "Hello from lambda land"

        }

        return {

            'statusCode': 200,

            'headers': {

                'Content-Type': 'application/json',

                'Access-Control-Allow-Origin': '*'

            },

            'body': json.dumps(transactionResponse)

        }

    except Exception as e:

        print(f"Error: {e}")

        return {

            'statusCode': 500,

            'headers': {'Access-Control-Allow-Origin': '*'},

            'body': json.dumps({'message': 'Internal Server Error', 'error': str(e)})

        }

Key Changes and Why They Work

1. Safe Parameter Extraction:
   
   
   Instead of directly accessing event['queryStringParameters'], I used .get() with default values to prevent KeyError exceptions.




2. Validation:
   
   
   The code now checks if required parameters are missing and raises a ValueError. This ensures we only process valid inputs.




3. Error Handling with Try-Except:
   
   
   Wrapping the logic in try...except allows us to catch errors and return a detailed response while logging the issue for debugging in CloudWatch.




4. CORS Headers:
   
   
   Adding Access-Control-Allow-Origin enables the frontend to communicate with the API successfully.

The Final Test

API Request

curl -X GET "https://<your-api-id>.execute-api.us-east-1.amazonaws.com/test/transactions?transactionId=123&type=credit&amount=1000"

Response

{

    "transactionId": "123",

    "type": "credit",

    "amount": "1000",

    "message": "Hello from lambda land"

}

Takeaways

1. 
   Validation is Crucial: Always validate inputs to ensure your application works as expected.
   


2. 
   Error Handling Simplifies Debugging: Wrapping your logic in try...except helps identify issues quickly.
   


3. 
   CORS Configuration Matters: If your API serves a frontend, always include CORS headers in the response.
   


4. 
   Logs Are Your Friend: Use print statements to log details in CloudWatch and understand what’s happening.

What’s Next?

Now that I’ve successfully implemented and tested this API, I’m moving on to integrating it with my S3 bucket for file uploads. This will involve:

• Generating pre-signed URLs in Lambda.
  


• Updating the frontend to handle file uploads.

Have you encountered similar challenges while working with serverless applications? Let’s discuss in the comments!