Aws-sam-cli: Debugging Golang code in SAM CLI

[tfnaylor]

I am able run my SAM Local Golang project just fine (get expected results, etc.) but cannot get my breakpoints to be hit in Visual Studio Code. I am using a Mac and the project is a simple REST API.

The VS Code debugger starts but the break icons never get filled in and breaks don't happen. My launch.json file configuration also gives me a warning that it doesn't recognize the debug type even though I can debug pure Golang applications on this machine without issue (Delve installed, etc.).

My launch.json file configurations section looks like this:

{
            "name": "Attach to SAM Local",
            "type": "go",
            "request": "attach",
            "address": "localhost",
            "port": 5858,
            "localRoot": "${workspaceRoot}/main.go",
            "remoteRoot": "/var/task"
}

I use the configuration to start the debugger, which seems to start normally (the debug control widget appears) and no errors are reported.

I suspect that the standard Go extension for VS Code (lukehoban.go) isn't compatible with this configuration. Is anyone else having this problem?

[afdabro]

I've ran into the same issue. It is a pain not being able to debug from SAM/VsCode. I keep the main func light and use a combination of DI and unit testing for the handle request func. Context and ProxyRequest are mockable making unit testing straight forward.

`
func init() {
// DI arguments init
}

func main() {
lambda.Start(handleRequest)
}

func handleRequest(ctx context.Context, request events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
return myDIHandleAPIRequest(ctx, request, ... any DI arguments ...)
}
`

[sanathkr]

SAM CLI doesn't have support for debugging Golang support yet. We need an entry point for Golang similar to https://github.com/awslabs/aws-sam-cli/blob/develop/samcli/local/docker/lambda_container.py#L131.

This should be fairly easy I would think. How do you usually start Go in debugging mode?

[austinlparker]

@sanathkr I started looking into this because we're using a lot of golang + lambda and I've made some progress. Go, out of the box, doesn't really have a debugger (other than gdb or whatever), delve (https://github.com/derekparker/delve) is the thing everyone uses afaik.

That said, the best way to get dlv inside the container is to actually modify the Dockerfile being used to include it. It looks like those are being maintained by someone else, though, and none of the other runtimes really have a 'change containers based on debugging being enabled or not' feature... I don't think it'd be terribly hard to do. But, I also don't think it'd be unreasonable to suggest that delve gets installed out of the box on those other images.

I'm trying to get a functioning POC going; So far I've got a new base container image with Delve installed, and an override for the entry point to start up delve as a server, and can connect to it. I'll keep hacking away and try to get it into a state where it can be PR'ed for review and discussion. Would appreciate feedback in the meantime on the basic idea.

[austinlparker]

Ok, I've got a first pass up that I wouldn't mind some eyes on... couple things I've noticed that I'm not sure how to address.

When running with start-api, the Python HTTP server side of things just keep trucking along - should it pause, or extend the timeout when debugging is enabled?

In addition, I don't have a 'debug flags' section included because I can't quite think of a great way to pass them into the container. Unlike other languages, where the entry point is being changed to call the language runtime, the golang one is still calling a wrapper binary... since the way the container works is by calling the wrapper application then running it as a subprocess, I needed to have delve be invoked by that wrapper. I suppose the debug wrapper could be modified more, but since it's a separate project from this that's meant to emulate the lambda container itself, I'm not sure how comfortable they'll be with drift.

[jfuss]

@austinlparker Regarding

When running with start-api, the Python HTTP server side of things just keep trucking along - should it pause, or extend the timeout when debugging is enabled?

What do you mean by things keep trucking along? The service should pause to wait for the Local Lambda to return.

[austinlparker]

It doesn't seem to be pausing forever. Looks like it timed out after around 60s?

Here's the logs: https://gist.github.com/austinlparker/f12ee4c9048834c99891384c433f4ec3

[jfuss]

Ahh. That's not specific to you (or go). We have an open PR to address it here #422. I haven't kept up on the thread, so will have to give it a read but I think there were some initial concerns with it. But I think that's out of scope for this.

[austinlparker]

Ah, yeah, that's what's happening. Yeah, doesn't seem related after skimming that thread.

[austinlparker]

So, I did a bit of a refactor on the container work (see https://github.com/lambci/docker-lambda/pull/97) that caused more changes to the work required on the SAM CLI side. I pushed a first pass of that on #495, but I think I'd like to generalize it some more. Looking at issues like #500, I think I can turn the delve_path into something like debugger_path, which would allow us to use a similar strategy for debugging netcore in the future (by mapping vsdbg into the lambda container).

That said, it feels a bit gnarly right now so I'd like to get thoughts from @jfuss / @sanathkr before doing cleanup and getting it mergeable.

[jfuss]

PR was merged, putting issue into 'stage/accepted' to mark this is waiting for a release.

[JanDeDobbeleer]

@jfuss I see the merge got reverted, any idea if/when this functionality will be available?

[jfuss]

@JanDeDobbeleer Sadly yes. :( We had to revert the commit due to some breaking functional/integration tests and didn't have enough time to resolve them before our v0.5.0 release. I am hoping we can get this into our next release.

[jfuss]

Updating labels indicting this is waiting on release

[napalm684]

Any eta on the release?

[afdabro]

Thank you!!

[jfuss]

Closing this as it was released in 0.6.0