Why does aws-sam-cli not support debug mode on os runtime (provided.al2 / provided.al2023)?

[lihuaabcder]

Hey,

As the title said, why does aws-sam-cli not support debug mode on os runtime (provided.al2 / provided.al2023)?

Currently I'm trying to use Golang to write lambda functions, and the current aws support for go is linux os runtime (provided.al2023).

And yes, aws-sam-cli does serve the Go lambda function by mocking a api gateway environment (using command like 'start-api').

I was trying to investigate is a way to debug Go lambda with 'Step-Through' break point stuff, and I was imagining is like maybe I could achieve this by using debug mode of sam-cli and delve debugger.

But it seems sam-cli doesn't support debug mode on os runtime. Why sam-cli doesn't have this feature and what is the difficulty?

Btw, does anyone know a way to make the 'step-through' break point debug for Golang at this case?

[hnnasit]

Hi @HLN177, thanks for opening the issue. I do see in the vscode toolkits docs page that debugging is supported for go1.x. Are you looking for a particular IDE to perform step-through debugging?

[lihuaabcder]

Hi @HLN177, thanks for opening the issue. I do see in the vscode toolkits docs page that debugging is supported for go1.x. Are you looking for a particular IDE to perform step-through debugging?

Hi @hnnasit, thanks for you reply.

At the moment, I am using vscode to develop go lambda function now. I did see this vscode toolkits and it seems this tool still only supports deprecated go1.X runtime, but the aws lambda only provide al2023 os runtime environment for Go now.

And yes, we could still use the old go1.X runtime for development and then use al2023 os runtime for production. However, this can lead to some follow-up problems due to inconsistency between the development and production environments.

And this isn't just a problem with go. Other languages that use the OS runtime in aws lambda, like C and rust, may also experience this problem as well.

Do you have any solution for this case?

[hnnasit]

Thanks @HLN177, I see what you mean. I'm marking this as a feature request.

[lihuaabcder]

Thanks @HLN177, I see what you mean. I'm marking this as a feature request.

Thanks for your help. May I ask when would this kind of feature be implemented in general? Actually I am trying to customize the source code of aws-sam-cli to achieve my requirement atm. I am think if I could build the docker image with a kind of debugger server and expose a debug port. Do you think it is a appropriate approach for this case?

[lantrix]

Same I'll give a voice to this too.

[error] SamLaunchRequestError: Invalid launch configuration: Debug Configurations with an invoke target of "code" require a valid Lambda runtime value, expected one of [python3.7, python3.8, java21, python3.9, dotnet6, java11, dotnet8, java17, java8.al2, go1.x, nodejs20.x, nodejs22.x, python3.10, java8, python3.11, python3.12, nodejs14.x, python3.13, nodejs16.x, nodejs18.x] [BadLaunchConfig]

Production is using provided.al2023 runtime to deploy Go functions on AL2023 to Lambda, but I can't debug it in the same runtime.

As announced in Jul 2023 you already plan to deprecate the go1.x runtime in line with the end-of-life of Amazon Linux 1 the end of this month, December 31, 2023. The go1.x lambda runtime is already deprecated and has been marked as Block function create since early 2024.

Just for reference the aws-sam debug type is also being used in VSCode as documented. I am using:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "aws-sam",
      "request": "direct-invoke",
      "name": "lambda handler",
      "invokeTarget": {
        "target": "code",
        "projectRoot": "${workspaceFolder}",
        "lambdaHandler": "handler.main"
      },
      "lambda": {
        "runtime": "provided.al2023",
        "payload": {},
        "environmentVariables": {}
      }
    }
  ]
}

[lantrix]

Still trying to successfully debug an provided.al2023 go lambda on VSCode, so tried remote debugging, but no luck here either.

GOOS=linux GOARCH=arm64 go build -o bootstrap
sam build -s .

Building codeuri: ./ runtime: provided.al2023 architecture: arm64 functions: ldbotFunction
Workflow GoModulesBuilder does not support value "False" for building in source. Using default value "True".
 Running GoModulesBuilder:Build

Build Succeeded

Built Artifacts  : .aws-sam/build
Built Template   : .aws-sam/build/template.yaml

But on invocation with -d when Running AWS SAM locally in debug mode it's the same issue.

DOCKER_HOST=unix://$HOME/.docker/run/docker.sock sam local invoke -d 5858 --event events/s3.json --env-vars .env
Invoking bootstrap (provided.al2023)
Local image is up-to-date
Error: Debugging is not currently supported for provided.al2023

It's not a very good position to be in for development of lambdas using the recommended runtime.

Update Dec 15, 2023: Lambda has since added Amazon Linux 2023 to the provided runtime family. We recommend that customers upgrading from the go1.x runtime use the new provided.al2023 runtime as their first preference. The provided.al2 runtime remains available and will be supported until at least June 30, 2025.

[lantrix]

Given we are developing on ARM based (Apple Silicon) I am unable to even use the go1.x architecture in the meantime for debugging with the AWS SAM CLI:

DOCKER_HOST=unix://$HOME/.docker/run/docker.sock sam local invoke -d 5858 --event events/s3.json --env-vars .env
No current session found, using default AWS::AccountId
Invoking bootstrap (go1.x)
Error: Runtime go1.x is not supported on 'arm64' architecture

TL;DR - AWS SAM CLI is completely useless for debugging on Apple Silicon when using Go. None of the SAM lambda runtimes you can use for Go are able to be used for debugging.

[AndiB42]

Are there any news here?