Live Lambda with `provided.al2023`

[oscartbeaumont]

Is it possible to make a Live Lambda work when doing a custom function with the provided.al2023 runtime, similar to what is shown in the Swift example.

Currently i'm using using Rust but my understanding is that SST doesn't need to know much about the underlying dev process as long as it takes care of reloading on code change. The AWS Rust runtime should be able to read the AWS_LAMBDA_RUNTIME_API environment variable and take over if the user was able to specifiy a dev command on the Function construct?

[jayair]

Not currently because sst dev needs to run that process locally and we only do that for Node.

But this dev command idea is interesting.

[oscartbeaumont]

Not that it's recommended at all but turns out you can kinda make this work right now by using the following in your sst.config.ts:

new sst.aws.Function("api", {
    ...($dev
        ? {
                runtime: "nodejs20.x",
                handler: "live.handler",
            }
        : {
                handler: "bootstrap",
                architecture: "arm64",
                runtime: "provided.al2023",
                bundle: build(),
            }),
});

and then live.js:

import { execSync } from "node:child_process";
import path from "node:path";

execSync("cargo watch -x 'run --bin lambda'", {
    stdio: "inherit",
    shell: "/bin/zsh",
    cwd: path.join(process.cwd(), ".."),
    env: {
        ...process.env,
        AWS_LAMBDA_FUNCTION_MEMORY_SIZE: "1024",
        AWS_LAMBDA_RUNTIME_API: `http://${process.env.AWS_LAMBDA_RUNTIME_API}`,
    },
});

// By stalling here we block SST's Lambda runtime from starting up, letting Rust's take over.
while (true) {
    await new Promise((resolve) => setTimeout(resolve, 10000));
}

However this doesn't just work out of the box due to incompatibilities between Live Lambda and the Rust Lambda runtime:

• Rust panics on AWS_LAMBDA_FUNCTION_MEMORY_SIZE env var not being defined. This should probally be defined by SST.
• Rust panics onAWS_LAMBDA_RUNTIME_API being an invalid URL. This is because the Rust runtime expects AWS_LAMBDA_RUNTIME_API to include http://. This is possibly a Rust runtime bug because the AWS Lambda docs show curl commands like http://$AWS_LAMBDA_RUNTIME_API which implies http:// isn't in AWS_LAMBDA_RUNTIME_API.
• Rust's Lambda runtime makes requests to $AWS_LAMBDA_RUNTIME_API/2018-06-01/* which means the requests hit SST at /lambda/{uuid}/2018-06-01/runtime/invocation/next instead of /lambda/{uuid}/runtime/invocation/next like the SST JS runtime does. I have created a patch to the Rust runtime here but this patch would break a regular deployment so I suspect this is something that should be fixed in Live Lambda.

[ryands17]

@oscartbeaumont Could I take the above solution and make it work temporarily? Also I was looking at Cargo lambda to temporarily invoke Rust lambdas.

[oscartbeaumont]

If you copy the code above and use the following in your root Cargo.toml:

[patch.crates-io]
lambda_runtime = { git = "https://github.com/oscartbeaumont/aws-lambda-rust-runtime", rev = "9d75ac7168dd6869bfa8deb1bc83018830dc617f" }

It will work with Live Lambda but be aware this Cargo patch will break your production deployment so you should comment it out before doing a proper deployment. I am going to look into doing a PR to SST to remove the need for this patch soon but i've had a busy couple of days.

For context i'm using this hack here.

I'm using Cargo Lambda for all of this because it takes care of using Cargo Zigbuild under the hood which itself takes care of cross compilation for any non-Rust code like openssl.