data did not match any variant of untagged enum LambdaRequest

[winstxnhdw]

I have rewritten the issue using your examples instead of my implementation to help with reproducibility.

Hi, I have been trying to write a simple Lambda function in Rust with the Function URL according to one of your examples here.

Testing the Lambda locally with cargo lambda correctly returns Command do something executed.

cargo lambda invoke something --data-ascii '{ "command": "do something" }'

There were no issues when executing the Lamba Test Event in the web GUI either. The problem only comes after deployment. Sending the exact POST request with Insomnia always returns an InternalServerError. CloudWatch complains of the following.

ERROR Lambda runtime invoke{requestId="5fb1fd9b-e8cd-48a4-b641-caf1ff16529b" xrayTraceId="Root=1-63e9481d-6db35e9e5220a0d061dd7904;Parent=0d074a1c13e2a3e8;Sampled=0"}: lambda_runtime: Error("missing field `command`", line: 1, column: 1118)

Okay fine, so I tried the example written in the lambda-http documentation here. I tested this again with Insomnia and CloudWatch now complains of the following.

thread 'main' panicked at 'called Option::unwrap() on a None value'

At this point, I was getting pretty desperate and did a fresh generation of cargo lambda new with the Function URL template selected. Unsurprisingly, this was just an exact copy of your http-basic-lambda example here. I did the same test with cargo lambda invoke as above and this time it returned the following.

Error: serde_json::error::Error

  × data did not match any variant of untagged enum LambdaRequest

This is my Cargo.toml.

[dependencies]
tokio = { version = "^1.25.0", features = ["macros"] }
reqwest = { version = "^0.11.14", default-features = false, features = ["json", "rustls-tls"] }
lambda_http = { version = "^0.7.3", default-features = false, features = ["apigw_http"] }
tracing-subscriber = { version = "^0.3", default-features = false, features = ["fmt"] }
tracing = { version = "^0.1", features = ["log"] }
serde = { version = "^1.0.152", features = ["derive"] }
serde_json = "^1.0.93"
futures = "^0.3.26"

[bnusunny]

You already got the basic-lambda example working. It does not work with Function URL. It is meant to be invoked via CLI or SDK directly.

For http-basic-lambda example, it does need to be accessed via a HTTP endpoint (api gateway, alb, or function url). The simplest way is to add a Function URL to the lambda function, then curl that endpoint.

[sondrelg]

I came over this issue a few days ago trying to figure out how to get around the same error. No longer sure if this applies to this issue exactly, but in case it's helpful, this is how I got mine working:

#[derive(Debug, Deserialize)]
pub struct Foo {
    bar: String,
}

async fn function_handler(event: LambdaEvent<Foo>) -> Result<Value, Error> {
    ...
    Ok(json!({"message": "success"}))
}

#[tokio::main]
async fn main() -> Result<(), Error> {
    // Set up logging
    tracing_subscriber::fmt()
        .with_max_level(tracing::Level::INFO)
        // Cloudwatch already adds a timestamp
        .without_time()
        // Turn off colors since colors are formatted weirdly by cloudwatch
        .with_ansi(false)
        .init();

    // Run our handler
    info!("Starting server");
    run(service_fn(function_handler)).await?;

    // Return nothing
    // Note: requests to the lambda will receive the return of the handler, not this
    Ok(())
}

I run it with pip install cargo-lambda && cargo lambda watch and test it with

❯ cargo lambda invoke --data-ascii '
{
  "foo": "bar"
}
'

[winstxnhdw]

Okay, I finally got this solved.

For http-basic-lambda example, it does need to be accessed via a HTTP endpoint (api gateway, alb, or function url). The simplest way is to add a Function URL to the lambda function, then curl that endpoint.

I had assumed that failing the test locally meant that the function would never work. This is wrong. The web test event and cargo lambda invoke will always give you the × data did not match any variant of untagged enum LambdaRequest error. This meant I could only test the function on the actual Lambda after it was deployed.

Solving that led me to this thread 'main' panicked at 'called Option::unwrap() on a None value' error again. I couldn't find out why until I looked into the the payload() implementation here. I needed to pass the application/json Content-Type for the method to figure out how it should be extracting the payload from the body. It seems I've been thoroughly spoilt by TypeScript.

Thank you.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for the maintainers of this repository to see.
If you need more assistance, please open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[sondrelg]

Thanks for the update @winstxnhdw. I was about a day behind you, and you just solved my problem hehe 👍 Does that mean we have to live with not being able to test the function easily locally?

I guess it would be possible to pass data equivalent to what's being passed from the gateway?

[bnusunny]

Yes, you could use the same event as API Gateway or ALB format to invoke function locally.

[winstxnhdw]

Yes, you could use the same event as API Gateway or ALB format to invoke function locally.

@bnusunny Any suggestions to write this idiomatically?

[sondrelg]

When testing, I personally would like to just do the same thing I do for a curl request, so if I curl like this:

curl -X POST -H "content-type: application/json" \
-d '
{
  "foo": "bar"
}' \
https://<id>.execute-api.eu-central-1.amazonaws.com/...

Then it would be very handy to be able to do

cargo lambda invoke --type http-gateway --data-ascii '                
{
  "foo": "bar"
}'

Is something like this possible today?

[bnusunny]

No, cargo lambda does not support that today. I don't think cargo lambda will be a curl replacement either.

If cargo lambda deploy shows the new http endpoint, you could access it with curl or Postman. Will this help?

[winstxnhdw]

If cargo lambda deploy shows the new http endpoint, you could access it with curl or Postman. Will this help?

Won't that still require us to deploy to production first?

No, cargo lambda does not support that today. I don't think cargo lambda will be a curl replacement either.

Also, it would be cool if this was properly documented.. I could even do the PR, if you're okay with it.

[bnusunny]

If you want to do it locally, SAM CLI could do that. Better support for rust in SAM CLI is coming.

Yes, feel free to send a PR.

[sondrelg]

I see now from the docs I can just curl http://localhost:9000/lambda-url/<my function>/. That seems to be exactly what I was after. Thanks for all the help 🙇

[greenwoodcm]

that's right. i wonder if there's an opportunity to make that clearer, for instance by having the cli take a --curl option that makes it do this by default. the pattern of finding that secret endpoint is a bit non-intuitive.