lambda_http thread 'main' panicked at 'failed to build request

[ymwjbxxq]

Hello,

APIGW has the following types:

• HTTP
• REST
• WebSocket

It seems to me that the lambda_http::Request works only for APIGW HTTP API and not for the rest of the types.

I am currently trying the REST API

your sample code:

use lambda_http::{handler, lambda_runtime::{self, Context, Error}, IntoResponse, Request, RequestExt};

#[tokio::main]
async fn main() -> Result<(), Error> {
    lambda_runtime::run(handler(|event: Request, ctx: Context| {
        execute(event, ctx)
    }))
    .await?;
    Ok(())
}

pub async fn execute(request: Request, _ctx: Context) -> Result<impl IntoResponse, Error> {
  println!("{:?}", request);

   Ok(format!(
        "hello {}",
        request
            .query_string_parameters()
            .get("name")
            .unwrap_or_else(|| "stranger")
    ))
}

error:
thread 'main' panicked at 'failed to build request: http::Error(InvalidUri(InvalidFormat))',

if you try to use for example
use aws_lambda_events::event::apigw::ApiGatewayProxyRequest;

you will have this:

type mismatch in closure arguments
required because of the requirements on the impl of `lambda_http::Handler<'_>`
found signature of `fn(ApiGatewayProxyRequest, lambda_http::Context) -> _`
expected signature of `fn(Request<lambda_http::Body>, lambda_http::Context) ->
note: required because of the requirements on the impl of `lambda_http::Handler<'_>` for `[closure@services/session-manager/src/bin/device.rs:6:33: 8:6]`
note: required by a bound in `Adapter`

using the normal lambda_runtime like this

 Ok(json!({
        "statusCode": 200,
         "headers": {
             "Content-Type": "application/json",
         },
         "body": {
             "message":  "ciao"
          }
    }))

you will get:

Received response. Status: 200
Endpoint response body before transformations: {"body":{"message":"ciao"},"headers":{"Content-Type":"application/json"},"statusCode":201}
 Execution failed due to configuration error: Malformed Lambda proxy response.
Method completed with status: 502

Thanks,
Dan

[nmoutschen]

Hey @ymwjbxxq !

I tried to reproduce your issue by creating a Lambda function backed by an API Gateway REST API, but it works for me: https://github.com/nmoutschen/repro-423

We had a similar issue not too long ago (#368), which was due to the internal struct being too strict when testing with sample events from the AWS Lambda console, or local tools such as with SAM local.

Could you walk me through how the way you've tested lambda_http::Request might differ from mine?

[ymwjbxxq]

Hi @nmoutschen

Here is the template to deploy API and Lambda.
You have the code, so I hope this will help you recreate the problem.

AWSTemplateFormatVersion: 2010-09-09
Transform: 'AWS::Serverless-2016-10-31'
Description: An Amazon API Gateway HTTP API and an AWS Lambda function.

##########################################################################
#  Parameters                                                            #
##########################################################################
Parameters:
  VpcId:
    Description: VPC where the APIGW will be created
    Type: String
  StageName:
    Description: The name of the stage is the first path segment in the Uniform Resource Identifier (URI) of a call to API Gateway
    Type: String
    Default: dev

##########################################################################
#  Global values that are applied to all resources                       #
##########################################################################
Globals:
  Function:
    MemorySize: 1024
    Architectures: ["arm64"]
    Handler: bootstrap
    Runtime: provided.al2
    Timeout: 29
    Environment:
      Variables:
        RUST_BACKTRACE: 1
        RUST_LOG: info

Resources:

##########################################################################
#  API Gateway REST API                                                  #
##########################################################################
  MyApi:
    Type: AWS::Serverless::Api
    Properties:
      StageName: !Ref StageName
      Name: !Ref AWS::StackName
      Description: An Amazon private REST API Gateway and an AWS Lambda function.
      EndpointConfiguration:
        Type: PRIVATE
        VPCEndpointIds: 
          - !Ref VpcId
      Auth:
        ResourcePolicy:
          CustomStatements: [{
            "Effect": "Allow",
            "Principal": "*",
            "Action": "execute-api:Invoke",
            "Resource": "execute-api:/*/*/*"
          }]

##########################################################################
#   Lambda Function                                                      #
##########################################################################
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: ../build/my-lambda
      Policies:
        - AWSLambdaBasicExecutionRole
        - Version: "2012-10-17"
          Statement:
            - Effect: Allow
              Action: 
                - dynamodb:UpdateItem
              Resource: !ImportValue DynamodbTableArn
      Environment:
        Variables:
          TABLE_NAME: !ImportValue DynamodbTableName
      Events:
        ApiEvents:
          Type: Api
          Properties:
            Path: /myPath
            Method: POST
            RestApiId: !Ref MyApi

Outputs:
  HttpApiEndpoint:
    Description: my endpoint.
    Value: !Sub "https://${MyApi}.execute-api.${AWS::Region}.amazonaws.com/${StageName}/"

go to the aws console, and try to post something

[ymwjbxxq]

@nmoutschen the input from the console is like at this issue:

calavera/aws-lambda-events#67

As you can see, I was using lambda_runtime but the return

Ok(json!({
        "statusCode": 200,
         "headers": {
             "Content-Type": "application/json",
         },
         "body": {
             "message":  "ciao"
          }
    }))

generate a malformatted error on the API, so I tried to move to lambda_http but it panics

[calavera]

I'm bringing the events from that crate into this one this weekend. I believe that should fix this problem.

[ymwjbxxq]

@calavera I tried this but I get

I think I need to implement some sort of mapping but you know it should just work ;)

[calavera]

yes, it's not a straightforward as changing the type in the handler signature, you should not have to worry about that.