Description
Is there an existing issue for this?
- I have searched the existing issues
Current Behavior
Dear LocalStack Support Team,
I am experiencing a persistent issue with Go Lambda functions using the provided.al2023 runtime in my LocalStack environment. The functions consistently fail to initialize, reporting a "connection refused" error when attempting to communicate with the internal Lambda Runtime API.
Problem Description:
My Go Lambda function's bootstrap executable, running within its dedicated container managed by LocalStack, is unable to connect to the Lambda Runtime API on 127.0.0.1:9001. This leads to the Lambda execution environment timing out during startup.
Here are relevant log snippets from a recent attempt:
- Lambda Internal Logs (showing "connection refused"):
[lambda b8634cd4ff4269b99d995cf1b4715799] Go Lambda bootstrap starting...
[lambda b8634cd4ff4269b99d995cf1b4715799] DEBUG: AWS_LAMBDA_RUNTIME_API value is [127.0.0.1:9001]2025/05/28 21:27:16 failed to get the next invoke: Get "http://127.0.0.1:9001/2018-06-01/runtime/invocation/next": dial tcp 127.0.0.1:9001: connect: connection refused
[lambda b8634cd4ff4269b99d995cf1b4715799] time="2025-05-28T21:27:16Z" level=warning msg="First fatal error stored in appctx: Runtime.ExitError"
[lambda b8634cd4ff4269b99d995cf1b4715799] time="2025-05-28T21:27:16Z" level=error msg="Init failed" InvokeID= error="Runtime exited with error: exit status 1"
This clearly shows my Go bootstrap failing to connect to the Runtime API.
- LocalStack Main Container Logs (showing startup timeout):
2025-05-28T22:22:37.139 WARN --- l.s.l.i.execution_environm : Execution environment c743dcb0e0d054370641b345dbd089bc for function arn:aws:lambda:us-east-1:000000000000:function:my-go-service-terraform:$LATEST timed out during startup. Check for errors during the startup of your Lambda function and consider increasing the startup timeout via LAMBDA_RUNTIME_ENVIRONMENT_TIMEOUT.
The timeout occurs consistently around 54-60 seconds, despite the Go Lambda being a lightweight function that should initialize well within this timeframe.
- LAMBDA_RUNTIME_ENVIRONMENT_TIMEOUT Not Applied (Secondary Concern):
I have attempted to increase LAMBDA_RUNTIME_ENVIRONMENT_TIMEOUT to 300 seconds in my docker-compose.yml file for the localstack service. However, the observed startup timeouts remain around 54-60 seconds, and inspecting the LocalStack main container's environment variables shows that LAMBDA_RUNTIME_ENVIRONMENT_TIMEOUT is not reflecting the set value. This suggests a potential issue with how this variable is parsed or applied in the :latest image.
Example from LocalStack creating the Lambda container, showing AWS_LAMBDA_FUNCTION_TIMEOUT (the function's timeout) being set, but no indication of LAMBDA_RUNTIME_ENVIRONMENT_TIMEOUT being passed to the LocalStack main container:
2025-05-28T22:21:43.171 DEBUG --- [et.reactor-5] l.u.c.docker_sdk_client : Creating container with attributes: {..., 'image_name': 'public.ecr.aws/lambda/provided:al2023',..., 'env_vars': {'AWS_LAMBDA_FUNCTION_TIMEOUT': 299,...}}
Environment Details:
LocalStack Version: LocalStack CLI 4.4.0, using Docker image localstack/localstack:latest.
Lambda Runtime: provided.al2023 (Go language).
Deployment Tool: Terraform.
LocalStack Startup: Via docker-compose.yml (with /var/run/docker.sock volume mount and LAMBDA_RUNTIME_ENVIRONMENT_TIMEOUT defined in the environment section).
Steps to Reproduce:
Start LocalStack using a docker-compose.yml that defines LAMBDA_RUNTIME_ENVIRONMENT_TIMEOUT=300 for the localstack service.
Deploy a Go Lambda function with runtime = "provided.al2023" using Terraform.
Invoke the Lambda function.
Observe the LocalStack logs for the consistent startup timeouts and the "connection refused" error from within the Lambda container.
Could you please provide clarification on the root cause of this consistent "connection refused" error on port 9001 for provided.al2023 runtimes, especially given that 60 seconds should typically be sufficient for Go Lambda initialization? Is there a known race condition or specific interaction with the provided.al2023 runtime in the :latest LocalStack image that could cause this? Any insights into why LAMBDA_RUNTIME_ENVIRONMENT_TIMEOUT is not being applied would also be greatly appreciated.
For now, I'm working with localstak 4.0. Thank you for your time and assistance.
Sincerely,
jaredejr
Expected Behavior
lambda starting.
How are you starting LocalStack?
With a docker-compose file
Steps To Reproduce
both localstack stard and docker compose
Environment
- OS: ubuntu
- LocalStack:
LocalStack version: CLI 4.4.0
LocalStack Docker image sha:
LocalStack build date:
LocalStack build git hash:Anything else?
the lambda:
package main
import (
"context"
"fmt"
"net/http"
"os"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func HandleRequest(ctx context.Context, request events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
fmt.Printf("Received request method: %s, path: %s", request.HTTPMethod, request.Path)
return events.APIGatewayProxyResponse{
StatusCode: http.StatusOK,
Body: "ok, funciona",
}, nil
}
func main() {
fmt.Println("Minha Go Lambda iniciando...")
fmt.Printf("Meu DEBUG: AWS_LAMBDA_RUNTIME_API value is [%s]", os.Getenv("AWS_LAMBDA_RUNTIME_API"))
defer func() {
if r := recover(); r != nil {
fmt.Printf("Recovered in main (bootstrap): %v\n", r)
}
}()
lambda.Start(HandleRequest)
fmt.Println("Go Lambda bootstrap finished lambda.Start (should not be reached if lambda.Start blocks)")
}
builded with: CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o bootstrap main.go