AWS Lambda Adapter: Expose aws_request_id and log_stream_name in SlackRequestHandler context

[agaiduk]

I would like to add two parameters from the AWS Lambda context into the BoltRequest context in AWS :

• aws_request_id
• log_stream_name

These parameters are useful for manual logging and are accessible directly from the context variable within lambda_handler(event, context) function when not in Bolt framework. I would like to also make them available in Bolt framework. Proposed code mirrors how bolt_req.context is currently populated in AWS Lambda adapter handler:

$ git diff
diff --git a/slack_bolt/adapter/aws_lambda/handler.py b/slack_bolt/adapter/aws_lambda/handler.py
index 1ba44dd..ba3e183 100644
--- a/slack_bolt/adapter/aws_lambda/handler.py
+++ b/slack_bolt/adapter/aws_lambda/handler.py
@@ -55,7 +55,11 @@ class SlackRequestHandler:
             bolt_req = to_bolt_request(event)
             # https://docs.aws.amazon.com/lambda/latest/dg/python-context.html
             aws_lambda_function_name = context.function_name
+            aws_request_id = context.aws_request_id
+            log_stream_name = context.log_stream_name
             bolt_req.context["aws_lambda_function_name"] = aws_lambda_function_name
+            bolt_req.context["aws_request_id"] = aws_request_id
+            bolt_req.context["log_stream_name"] = log_stream_name
             bolt_req.context["aws_lambda_invoked_function_arn"] = context.invoked_function_arn
             bolt_req.context["lambda_request"] = event
             bolt_resp = self.app.dispatch(bolt_req)

I am open to implementing this feature myself if there is desire to add it to bolt-python.

Category (place an x in each of the [ ])

• slack_bolt.App and/or its core components
• slack_bolt.async_app.AsyncApp and/or its core components
• Adapters in slack_bolt.adapter
• Others

Requirements

Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

[zimeg]

Hey @agaiduk! 👋 To me this seems like a safe and solid enhancement! I'm all for adding more context to requests. Your implementation would be super appreciated too, but perhaps @seratch or @WilliamBergamin have other insights into this area?

[seratch]

Thanks for the suggestion! The reason why aws_lambda_function_name and aws_lambda_invoked_function_arn are copied to context object is that they are necessary for enabling lazy listeners to function. I hesitate to add others by default as there are much more properties in the AWS context and most developers really don't need it.

My suggestion for this need is to add a function like attach_custom_properties(aws_context, bolt_context) to the constructor arguments (as an optional one) instead. With this approach, you can add those properties and others can add more as necessary.