Open ryancormack opened 10 months ago
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.
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.
Sorry, we will update the document soon.
@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?
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.
However, you could still access those environment variables from your run.sh
script.
@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!
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 asrequest_id
. The Rust runtime (and others) get this from thelambda-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 withawsRequestId
, .NET withAwsRequestId
and Python withaws_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 theContext
object exposed by the Lambda Types