Skip to content
This repository has been archived by the owner on May 16, 2023. It is now read-only.

Lambda Handler fails to execute when using ApiGatewayV2CustomAuthorizerV1Request or ApiGatewayV2CustomAuthorizerV2Request #131

Open
ygormartins opened this issue Jan 6, 2023 · 5 comments

Comments

@ygormartins
Copy link

ygormartins commented Jan 6, 2023

I'm trying to create a custom ApiGatewayV2 authorizer lambda for a WebSocket API using ApiGatewayV2CustomAuthorizerV1Request or ApiGatewayV2CustomAuthorizerV2Request, but the lambda fails to run in both cases.
It runs the main() function with no issues, but code inside the handler_fn is being completely ignored, and no error whatsoever is being thrown. I've tried using other types, such as ApiGatewayCustomAuthorizerRequest, and they work just fine, but they're incompatible with the API Gateway version and return incorrect/missing data.

Sometimes it outputs an "Unknown.Runtime" error message directly in the lambda logs.

I'm using lambda_runtime and aws_lambda_events, both v0.7.0.
I've tried v0.7.1 and v0.7.2 and had the exact same result.

Here's the code:

use aws_lambda_events::apigw::ApiGatewayV2CustomAuthorizerV2Request;
use lambda_runtime::{service_fn, Error, LambdaEvent};

#[tokio::main]
async fn main() -> Result<(), Error> {
    println!("Running main function");

    let handler = service_fn(|event| handler_fn(event));

    lambda_runtime::run(handler).await?;

    println!("Finished running");

    Ok(())
}

async fn handler_fn(
    event: LambdaEvent<ApiGatewayV2CustomAuthorizerV2Request>,
) -> Result<ApiGatewayV2CustomAuthorizerV2Request, Error> {
    println!("Query params:");
    println!("{:#?}", event.payload.query_string_parameters);

    Ok(event.payload)
}

Here are the lambda logs:

2023-01-05T20:53:34.722-03:00 | Running main function
2023-01-05T20:53:34.729-03:00 | START RequestId: e320b0aa-6596-4396-abb5-2989ebfad615 Version: $LATEST
2023-01-05T20:53:34.731-03:00 | END RequestId: e320b0aa-6596-4396-abb5-2989ebfad615
2023-01-05T20:53:34.731-03:00 | REPORT RequestId: e320b0aa-6596-4396-abb5-2989ebfad615 Duration: 1.57 ms Billed

And here's my lambda configuration:

Screenshot from 2023-01-05 20-56-48
Screenshot from 2023-01-05 20-57-14

Also, what's the difference between ApiGatewayV2CustomAuthorizerV1Request and ApiGatewayV2CustomAuthorizerV2Request?

Thanks!

@calavera
Copy link
Owner

calavera commented Jan 6, 2023

This discussion might be relevant to what you're trying to do: awslabs/aws-lambda-rust-runtime#530

@ygormartins
Copy link
Author

This discussion might be relevant to what you're trying to do: awslabs/aws-lambda-rust-runtime#530

This refers to AWS SAM role issues with APIGateway authorisers (had the exact same issue yesterday!)

In my case, serde was failing to serialise the event payload because some fields from both V1 and V2 types weren't present (such as http_method from V1) and weren't marked as Option<>.
I believe this is happening because I'm using a custom authoriser for a WebSocket API, and some fields are different from HTTP ones.

I believe there's two ways to fix this:

  • Create a specific type for WebSocket authorisers
  • Modify the existing types to use Option<> for fields that aren't in both HTTP and WebSocket APIs and maybe add any missing fields

For now, I have created a custom struct with only the fields I'll be using in my lambda

@naokiri
Copy link

naokiri commented Jan 9, 2023

Reporting another case related to this problem.

I've used ApiGatewayV2CustomAuthorizerV2Request for an HTTP APIGatewayV2, payload version 2.0, and the API didn't work and the cloudwatch log of $context.authorizer.error recorded

"The Lambda Authorizer function returned the following error: missing field cookies at line 1 column 1439. Check your Lambda function code and try again."

So this issue happens not only for WebSocket API but also when the field is not actually necessary for HTTP API case too. I think adding Option<> is a better solution in short term.

@calavera
Copy link
Owner

@naokiri the error with cookies should be solved in 0.7.3. I believe #123 fixed it, but it was never released until today.

@naokiri
Copy link

naokiri commented Jan 10, 2023

@calavera v0.7.3 worked. Thank you!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants