Skip to content

ClientContext, CognitoIdentity are not initialized #249

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
rimutaka opened this issue Aug 4, 2020 · 5 comments · Fixed by #426
Closed

ClientContext, CognitoIdentity are not initialized #249

rimutaka opened this issue Aug 4, 2020 · 5 comments · Fixed by #426
Assignees
Labels
bug Something isn't working

Comments

@rimutaka
Copy link
Contributor

rimutaka commented Aug 4, 2020

Neither pub client_context: Option<ClientContext> nor pub identity: Option<CognitoIdentity> from Context structure are ever set to any value.
They are declared, but are never used.

Relates to PR #248

@rimutaka
Copy link
Contributor Author

I suggest we use an extra field in Context to capture any additional fields of headers AWS may send our way. The change them faster than we update our structutes.

@rimutaka
Copy link
Contributor Author

pub env_config: Config, from Context was never set. I added a fix in rimutaka@b10f35e, but it depends on PR #244, so can't do another PR until those changes are merged.

Sample output for Context from inside the handler:

Context: Context { request_id: "4acd4e97-8233-45c3-a54e-1141951b2fd6", deadline: 1597898368541, invoked_function_arn: "arn:aws:lambda:ap-southeast-2:028534811986:function:lambda-debug-proxy", xray_trace_id: "Root=1-5f3dfe76-03fec66020c8320006819e80;Parent=39b030af6801381a;Sampled=0", client_context: None, identity: None, env_config: Config { endpoint: "127.0.0.1:9001", function_name: "lambda-debug-proxy", memory: 128, version: "$LATEST", log_stream: "2020/08/20/[$LATEST]577480e8a3cf4c79a727ffbc3c311f61", log_group: "/aws/lambda/lambda-debug-proxy" } }

@jkshtj jkshtj added the bug Something isn't working label Jan 21, 2021
@bahildebrand
Copy link
Contributor

@rimutaka what is the status on this now that #244 has been merged?

@rimutaka
Copy link
Contributor Author

@bahildebrand Blake, I lost track of it, but a quick look at the master branch tells me it's not really finished. I stand to be corrected, though.

lambda-runtime

  1. The structures are there (https://github.com/awslabs/aws-lambda-rust-runtime/blob/master/lambda-runtime/src/types.rs#L83 and https://github.com/awslabs/aws-lambda-rust-runtime/blob/master/lambda-runtime/src/types.rs#L109)
  2. The structures seem to remain unpopulated (https://github.com/awslabs/aws-lambda-rust-runtime/blob/master/lambda-runtime/src/types.rs#L121)

lambda-http

  1. Those structures are different and should be populated from the APIGW JSON request during deserialization, so should work, but the test JSON document has those fields empty. I think we need at least one test with those values in.

From what I remember, I put the structs in, copied their descriptions from AWS docs and left it at that because I was not using Cognito at the time and had no easy way of testing. That's what was merged.

The project I'm working on will need this feature at some point. I'm happy to complete this issue as soon as I get to that.

@davidbarsky
Copy link
Contributor

If I recall correctly, the CognitoIdentity and ClientContext values are only filled by early iterations of the mobile SDKs that directly invoked a Lambda function. This pattern is now discouraged and we now suggest that customers invoke Lambda functions through an API Gateway or an ALB. While we can fill in these values, I think that ClientContext and CognitoIdentity should be marked as #[deprecated] in the API.


In your use-case, can you avoid using these fields/invoking Lambda functions directly?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants