Skip to content

Add support in Tracer for additional arguments in the lambda_handler #242

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
hanninen opened this issue Dec 13, 2020 · 4 comments
Closed

Comments

@hanninen
Copy link

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?

@hanninen hanninen added feature-request feature request triage Pending triage from maintainers labels Dec 13, 2020
@heitorlessa
Copy link
Contributor

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

@heitorlessa heitorlessa added need-customer-feedback Requires more customers feedback before making or revisiting a decision need-more-information Pending information to continue pending-close-response-required and removed triage Pending triage from maintainers need-customer-feedback Requires more customers feedback before making or revisiting a decision feature-request feature request need-more-information Pending information to continue labels Jan 11, 2021
@heitorlessa heitorlessa added the need-more-information Pending information to continue label Jan 15, 2021
@hanninen
Copy link
Author

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

heitorlessa added a commit that referenced this issue Jan 17, 2021
* improv: support kwargs

* chore: add a comment to not forget about async tracer
@heitorlessa heitorlessa added pending-release Fix or implementation already in dev waiting to be released and removed need-more-information Pending information to continue labels Jan 17, 2021
@heitorlessa
Copy link
Contributor

Thanks @hanninen - It'll be available tomorrow in the 1.10 release

@heitorlessa
Copy link
Contributor

hey @hanninen - This is now available on 1.10 on PyPi and on SAR :)

Closing this now, and thank you for raising it

@heitorlessa heitorlessa removed the pending-release Fix or implementation already in dev waiting to be released label Jan 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

2 participants