Handle error conditions from Lambda function in Runtime API

[ghost]

Issue #, if available: DOTNET-7865

Description of changes:
In this PR, we handle error conditions for when the lambda function itself fails. There are 2 main components.

1. Handling the error in the lambda runtime api.
2. Handling the error at the api gateway layer

Handling the error in the lambda runtime api

For handling the error at the lambda runtime api layer we need to mimic how lambda functions behave when they fail. The behavior is described here https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html#API_Invoke_ResponseSyntax. The TLDR version is that they will set the status code to 200, populate the payload with the event.ErrorResponse object and also set the X-Amz-Function-Error header to the event.ErrorType.

Handling the lambda error for api gateway

For handling the error at the api gateway layer, it seems that api gateway will just show internal server error when the lambda has an error behind the scenes, so I have done the same.

Testing/Validation

Testing lambda runtime api

In order to verify the accuracy of how i am doing the error handling for the lambda runtime api, did the following. I deployed a lambda function that looks like this (it will throw a null pointer exception and fail)

exports.handler = async (event) => {
var x;
return x.toUpper()
};

I then created a console app to invoke the lambda function directly.

var response = await lambdaClient.InvokeAsync(request);

    // Process the response
    if (response.StatusCode == 200)
    {
        Console.WriteLine("Lambda function invoked successfully.");
        string responsePayload = System.Text.Encoding.UTF8.GetString(response.Payload.ToArray());
        Console.WriteLine($"Response payload: {responsePayload}");
    }
    else
    {
        Console.WriteLine($"Error invoking Lambda function. Status code: {response.StatusCode}");
    }

I was able to validate that the response code was 200, the responsePayload contained the same evnt.ErrorResponse object that i populate in my code, and that the X-Amz-Function-Error was the same to the one that i populate in my code. (sample fiddler response below)

HTTP/1.1 200 OK
Date: Wed, 29 Jan 2025 16:53:47 GMT
Content-Type: application/json
Content-Length: 308
Connection: keep-alive

X-Amz-Function-Error: Unhandled

{"errorType":"TypeError","errorMessage":"Cannot read properties of undefined (reading 'toUpper')","trace":["TypeError: Cannot read properties of undefined (reading 'toUpper')","    at exports.handler (/var/task/index.js:3:10)","    at Runtime.handleOnceNonStreaming (file:///var/runtime/index.mjs:1173:29)"]}

Testing api gateway for handling errors

1. For api gateway, i did similar. I used the same lambda function as above and just hooked up an api gateway and then went to the api gateway url and found that it just returned Internal Server Error.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[ghost]

i just put this in its own function so i can re-use it

[ghost]

I kept these function (ToErrorResponse) inside the extensions class because I wasn't sure else where to put them, even though they really arent being used as extensions. I figured it's fine for now but if anyone has better ideas let me know.

[ghost]

i tried for a couple of hours to have unit tests for the api gateway process and lambda runtime api service class, but with the way the current classes are written they are difficult to mock.

[normj]

Change looks good. Can we get some tests added to the PR?

[ghost]

@normj i was able to add unit tests for the lambdaruntimeapitests class only. With the way the current ApiGatewayProcess class is written, its not easy to mock/test the stuff that happens in the appl/catchall block. I also figured adding an integration test for just this api gateway behavior was overkill (since it would just be testing that the result is internal server error). let me know your thoughts