Inconsistent Lambda Context object

[ryancormack]

Summary

The tool supports forwarding the Lambda Context object via the x-amzn-lambda-context header. This was added here and does largely what it says on the tin.
However, given the library is written in Rust, it is using the Rust typings, objects and functions which uses a different casing but also just different names of the properties. For example, the Rust library and runtime have the AWS Request ID defined as request_id. The Rust runtime (and others) get this from the lambda-runtime-aws-request-id header that is passed by the Lambda Service when invoking a new function.
However, all other runtimes then deserialise this in different ways. The Rust object is incompatible with the types from all the other runtimes including: Node with awsRequestId, .NET with AwsRequestId and Python with aws_request_id.

I appreciate this isn't a problem with this extension in particular and more of an inconsistency across all of the runtimes and how they serialise the Context object.

Proposed Solution

It might just be that the documentation in the Readme could be updated to reflect this, particularly with the reference to the Node runtime.

Would this library also consider exposing some types/interfaces that others may use in their code?

Motivation

I understand this could likely just be 'fixed' with a Readme update, but I wanted to create the issue to discuss if there is anything that could possibly be done to better support strong typing of the Context object by any possible language/framework/runtime that may want to use this in the future. I ended up going down a rabbit hole to see how/where everything was getting set and passed from the Rust lib to my Node application. I had hoped to deserialise the x-amzn-lambda-context header to the Context object exposed by the Lambda Types

[bnusunny]

Thanks for raising this issue. We will update the README with the structure of Lambda Context Objects. It has a different structure depending on the event trigger.

[vicary]

This one caught me in surprise. Especially README links to AWS SDK for Node.js instead of Rust, when in reality the context object is in Rust without any object name conversions.

[bnusunny]

Sorry, we will update the document soon.

[vicary]

@bnusunny Thanks for the reply, hopefully it gets fixed soon.

We also found that log_stream and log_group are empty strings when it shouldn't, do you think it's a bug in the Rust SDK itself?

[bnusunny]

No. Lambda Web Adapter is a Lambda extension. It does not have access to some environment variables of the function. Here is the list from the document, under "Permissions and configuration" section.

• AWS_EXECUTION_ENV
• AWS_LAMBDA_LOG_GROUP_NAME
• AWS_LAMBDA_LOG_STREAM_NAME
• AWS_XRAY_CONTEXT_MISSING
• AWS_XRAY_DAEMON_ADDRESS
• LAMBDA_RUNTIME_DIR
• LAMBDA_TASK_ROOT
• _AWS_XRAY_DAEMON_ADDRESS
• _AWS_XRAY_DAEMON_PORT
• _HANDLER

However, you could still access those environment variables from your run.sh script.

[vicary]

@bnusunny I agree that this is not the job for this repo, just made a tiny shim for Deno https://jsr.io/@vicary/lambda-adapter to make it align with official docs for Node.js. Hopefully others will step up and do the same for other supported languages!