Add support in Tracer for additional arguments in the lambda_handler

[hanninen]

Is your feature request related to a problem? Please describe.
We have a decorator that injects a new argument to the lambda_handler and this is not compatible with the current implementation of the Tracer.capture_lambda_handler, as it calls the passed lambda_handler with the standar event and context arguments only.

Describe the solution you'd like
Allow other decorators to add new arguments to the lambda_handler and pass **kwargs in addition to the event and context variables to the lambda_handler call.

Describe alternatives you've considered
Can the Tracer.capture_lambda_handler be changed not to call the lambda_handler, but pass down the decorated function with the tracer instance?

[heitorlessa]

Hi @hanninen, thanks for raising this - We're returning from PTO this week.

Do you mean like this?

...
@tracer.capture_lambda_handler
def handler(event, context, **kwargs):
    return dummy_response

If so, sure thing, it'd be a no brainier for us to ship it in the next release - let us know!

Here's a test to exemplifies this better:

def test_capture_lambda_handler_with_additional_kwargs(dummy_response):
    # GIVEN tracer lambda handler decorator is used
    tracer = Tracer(disabled=True)

    # WHEN a lambda handler signature has additional keyword arguments
    @tracer.capture_lambda_handler
    def handler(event, context, my_extra_option=None, **kwargs):
        return dummy_response

    # THEN tracer should not raise an Exception
    handler({}, {}, blah="blah")

Thank you

[hanninen]

Yes **kwargs should do it just fine, thanks!