Can't find way to locally debug a Native AOT annotation framework-based HttpApi with Lambda Test tool

[lorenh]

( Updated with some forward progress below, but still not fully able to debug )
( Updated once again with some more forward progress below, but still wondering if this is just how it is )

This is my first experiment with the Annotations Framework, and I'm struggling with a local debug flow. Our previous Lambdas have been the aspnetcore style with two different entry points, one for local and one for lambda, and local F5 debugging "just works".

So now I'm excited to try out the Native AOT with dotnet8 blueprint. When I have it set up the way I thought I was supposed to, the Lambda test tool pops up, and when I pass in a request based on the "API Gateway V2 HTTP API" structure, the Lambda test tool just report an error

Invalid format for function handler string SimulatorAutomationController. Format is <assembly>::<type-name>::<method>.

My launchsettings.json looks like this:

{
  "profiles": {
    "Mock Lambda Test Tool": {
      "commandName": "Executable",
      "executablePath": "%USERPROFILE%\\\\.dotnet\\\\tools\\\\dotnet-lambda-test-tool-8.0.exe",
      "commandLineArgs": "--port 5050",
      "workingDirectory": ".\\\\bin\\\\$(Configuration)\\\\net8.0",
      "environmentVariables": {
        "DOTNET_ENVIRONMENT": "Local"
      }
    }
  }
}

I know people are developing locally somehow, I just can't figure out the combination to get it to work. There is a lot of generation magic going on behind the scenes with the Annotation Framework and I'm just not connecting the dots somehow. At present, the only way I can execute my code is to publish it to AWS Lambda in the cloud and run it there. Can I ask how others are debugging locally without deploying?

-- Follow up

I feel like I'm making some progress, I had completely missed the "Executable Assembly" page in the test tool. Now I see that and I know to change my startup profile to something like this:

{
  "profiles": {
    "Lambda Runtime API": {
      "commandName": "Project",
      "environmentVariables": {
        "AWS_LAMBDA_RUNTIME_API": "localhost:5050",
        "AWS_PROFILE": "default",
        "AWS_REGION": "us-east-1"
      }
    }
  }
}

and start the lambda test tool ahead of time with "dotnet lambda-test-tool-8.0" (Thanks to Ashish #1539 (comment))

However, now when I set breakpoints in my function and start the debugger. It just ends right away, no queued events seem to be getting read, and no breakpoints are getting hit.

Once again, I know people are successfully developing using the Annotations Framework, but I must be doing something wrong.

-- Follow up 2 (sorry about the play-by-play here, the story is unfolding as I go)

OK, so I FINALLY got it to stop on a breakpoint. After decompiling the generated "Main()" method I see that the key to getting it to run code is to set the "ANNOTATIONS_HANDLER" environment variable.

So once I changed my launch setting profile to this, it worked. Is this what you all are doing? Then do you create different launch profiles for each function in your Functions class in cases where there may be many?

{
  "profiles": {
    "Lambda Runtime API": {
      "commandName": "Project",
      "environmentVariables": {
        "AWS_LAMBDA_RUNTIME_API": "localhost:5050",
        "AWS_PROFILE": "default",
        "AWS_REGION": "us-east-1",
        "ANNOTATIONS_HANDLER": "GetStatus"                    <================   Added this
      }
    },
    "Debug Function 2": {
      "commandName": "Project",
      "environmentVariables": {
        "AWS_LAMBDA_RUNTIME_API": "localhost:5050",
        "AWS_PROFILE": "default",
        "AWS_REGION": "us-east-1",
        "ANNOTATIONS_HANDLER": "Function2"
      }
    },
    etc...
  }
}

Now I seem to be having issues with the application assembly getting locked by the test tool in the bin folder so I can't build code again without leaving visual studio and test tool completely to free the assembly. This whole inner loop development cycle just seems so clunky, I have to be missing something.

[ashishdhingra]

@lorenh Good morning. I was able to debug the Annotations framework code using Lambda test tool based on guidance provided in #1498 (comment). After the Lambda test tool is launched:

• Select appropriate generated Function handler (for my case, I selected AnnotationsSampleFunctionsAddGenerated)
• Select API Gateway V2 HTTP API in the Example Requests drop down.
• In the Function Input JSON, scroll to the bottom, and specify pathParameters. For my case, I specified values for x and y as shown below:

     "body": "Hello from Lambda",
    "pathParameters": { "x": "5", "y": "9" },
    "isBase64Encoded": false,
    "stageVariables": {
      "stageVariable1": "value1",
      "stageVariable2": "value2"
    }
  }

• Clicking on Execute Function generated the desired output:
  

Hope this helps.

Thanks,
Ashish

[lorenh]

I think the difference here is that I am trying to use the Native AOT blueprint which generates a different Handler in serverless.template (Which I apologize, I didn't mention prominently enough in the original post)

When I try your steps in a project generated with the Native AOT blueprint I get

"Invalid format for function handler string AWSServerless4. Format is <assembly>::<type-name>::<method>."

Native AOT blueprint generates a the Handler like this

  "Properties": {
    "Runtime": "dotnet8",
    "CodeUri": ".",
    "MemorySize": 512,
    "Timeout": 30,
    "Policies": [
      "AWSLambdaBasicExecutionRole"
    ],
    "PackageType": "Zip",
    "Handler": "AWSServerless4",     <====================== 
    "Environment": {
      "Variables": {
        "ANNOTATIONS_HANDLER": "GetFunctionHandler"
      }
    },

(Could it have been: "Handler": "AWSServerless4::AWSServerless4.GeneratedProgram::Main", ?)

Whereas the Annotations Framework blueprint generates

  "Properties": {
    "Runtime": "dotnet8",
    "CodeUri": ".",
    "MemorySize": 512,
    "Timeout": 30,
    "Policies": [
      "AWSLambdaBasicExecutionRole"
    ],
    "PackageType": "Zip",
    "Handler": "AWSServerless4::AWSServerless4.Functions_Subtract_Generated::Subtract",    <=============

[lorenh]

OK, I think I finally figured out a crucial piece of this. I can't start the mock lambda test tool in the project directory, you have to get it running somewhere else so it doesn't try and lock the output assembly rendering it impossible to build & debug your function project.

So I opened a terminal in C:\Temp (just someplace far away from the project I was debugging)

dotnet lambda-test-tool-8.0

Then immediately go to the "Executable Assembly" page. The "Test Function" page is not usable with the Native AOT style projects. Queue up a request, then debug your project using a launchSettings.json profile similar to this:

    "GetVersion": {
      "commandName": "Project",
      "environmentVariables": {
        "AWS_LAMBDA_RUNTIME_API": "localhost:5050",
        "AWS_PROFILE": "default",
        "AWS_REGION": "us-east-1",
        "ANNOTATIONS_HANDLER": "GetVersion"
      }
    },

Next thing I'm trying to figure out is why you can't just start up the lambda test tool in any old empty folder. It looks like it is looking for something to exist so it can load a local Lambda runtime... whatever that means. I already have determined I don't want to run it directly in my project folder because it likes to lock files, so I need to run it somewhere else. What's the minimum set of things to exist in that "somewhere else" folder so I can just get it going enough to jump over to the Executable Assembly page.

So ultimately this seems to come down to be a few questions about the Mock testing tool.

1. Why is it locking the project output assembly for me while it is running? I've used the tool before on other lambda functions of various styles, and it doesn't seem to do this. Just on the Native AOT blueprint based one.

2. Is there a command line argument I could start up the Mock testing tool with to get it to NOT try and do anything with the output assembly (resulting in it getting locked) and just start up in a minimal mode so I can use the "Executable Assembly" page (or equivalent functionality) only.

3. Will there ever be a way to edit and save custom request payloads directly from the "Executable Assembly" page. (Currently this functionality exists only in the "Test Function" page)?

[ashishdhingra]

For testing Native AOT based Lambda functions, please refer instructions at Testing Executable Assemblies.