Hello! A quick one here, as this tripped me up again today as I was working on a different development machine!

I wanted to start writing a new AWS Lambda function in Go, so to make sure my dev machine was set up OK, I used sam init to create me a simple templated hello-world app so I could check everything was ok.

Upon deploying the app, and calling the API Gateway URL, I got this unexpected error:

➜  aws-lambda-go-helloworld curl https://<apigateway>.execute-api.eu-west-1.amazonaws.com/Prod/hello/
{"message": "Internal server error"}

Odd. What do the logs show?

➜  aws-lambda-go-helloworld sam logs
2022/10/01/[$LATEST]b8924828b6c942f8a70d855f20c99259 2022-10-01T16:22:13.145000 START RequestId: 522f1627-7cfe-4ce0-851f-1a16c2d1dd90 Version: $LATEST
2022/10/01/[$LATEST]b8924828b6c942f8a70d855f20c99259 2022-10-01T16:22:13.145000 fork/exec /var/task/hello-world: no such file or directory: PathError
null

When this happened the first time, I fell down the rabbit hole of asking myself, "How does AWS Lambda even work?" which honestly is quite an interesting story in itself and led me to learning about Firecracker, but for this simple story the problem is that the Go binary is not readable by the execution environment, so a bit unintuitively gives you a 'file not found' error.

The fix in this case is very simple. Simply disable the CGO_ENABLED go env setting: go env -w CGO_ENABLED=0

When I deployed this time, I could see a much fatter binary sitting in S3, and the lambda now executed OK.

2022-10-01 17:20:26       2461 sam-helloworld/2c093bbaa8129e0808252bc6d0f7c3eb
2022-10-01 17:29:10    4948769 sam-helloworld/9223a16c8b0a07cb170498794870ddf5

➜  aws-lambda-go-helloworld curl https://<apigateway>.execute-api.eu-west-1.amazonaws.com/Prod/hello/
Hello, 34.241.46.148

2022/10/01/[$LATEST]6553699a98d048f7a8cc46ceb300d5b0 2022-10-01T16:39:15.614000 START RequestId: 5ef38541-955c-4dd9-97de-774df7cce35b Version: $LATEST
2022/10/01/[$LATEST]6553699a98d048f7a8cc46ceb300d5b0 2022-10-01T16:39:15.615000 Hello everybody!
2022/10/01/[$LATEST]6553699a98d048f7a8cc46ceb300d5b0 2022-10-01T16:39:16.140000 Hello Dr. Nick!
2022/10/01/[$LATEST]6553699a98d048f7a8cc46ceb300d5b0 2022-10-01T16:39:16.141000 END RequestId: 5ef38541-955c-4dd9-97de-774df7cce35b
2022/10/01/[$LATEST]6553699a98d048f7a8cc46ceb300d5b0 2022-10-01T16:39:16.141000 REPORT RequestId: 5ef38541-955c-4dd9-97de-774df7cce35b    Duration: 527.02 ms    Billed Duration: 528 ms    Memory Size: 128 MB    Max Memory Used: 36 MB    Init Duration: 116.70 ms

CGO seems to be enabled by default, and while I expect many people make use of 'Go with C Bindings' functionality, it's not something I need and in fact usually causes fun little issues like this to surface! But I am happy it was a quick fix, and now I can get back to writing my actual app, happy that my macOS dev machine is going to produce lambda-compatible Go binaries for me!