Skip to content
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

feat: apply $AWS_LAMBDA_EXEC_WRAPPER if set #524

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

RomainMuller
Copy link

@RomainMuller RomainMuller commented Oct 16, 2023

Managed AWS Lambda runtimes wrap the function's runtime entry using a script specified by the AWS_LAMBDA_EXEC_WRAPPER environment variable, however this is not performed by provided runtimes (provided, provided.al2, go1.x).

This adds a new WithEnableExecWrapper() option that re-startes the current process after wrapping it in the wrapper to emulate the behavior of other lambda runtimes, although this will cause initialization of some other go packages to be run twice, which will have an impact on cold start times.

See also: https://docs.aws.amazon.com/lambda/latest/dg/runtimes-modify.html#runtime-wrapper

Fixes #523


By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Managed AWS Lambda runtimes wrap the function's runtime entry using a script
specified by the `AWS_LAMBDA_EXEC_WRAPPER` environment variable, however this is
not performed by provided runtimes (`provided`, `provided.al2`, `go1.x`).

This adds an `init` function that re-startes the current process after wrapping
it in the wrapper to emulate the behavior of other lambda runtimes, although
this will cause initialization of some other go packages to be run twice, which
will have an impact on cold start times.

See also: https://docs.aws.amazon.com/lambda/latest/dg/runtimes-modify.html#runtime-wrapper

Fixes aws#523
@codecov-commenter
Copy link

codecov-commenter commented Oct 16, 2023

Codecov Report

Attention: 11 lines in your changes are missing coverage. Please review.

Comparison is base (c4e28da) 72.63% compared to head (d4c6b0d) 72.24%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #524      +/-   ##
==========================================
- Coverage   72.63%   72.24%   -0.39%     
==========================================
  Files          26       27       +1     
  Lines        1407     1427      +20     
==========================================
+ Hits         1022     1031       +9     
- Misses        314      323       +9     
- Partials       71       73       +2     
Files Coverage Δ
lambda/wrapper.go 75.00% <75.00%> (ø)
lambda/handler.go 91.53% <0.00%> (-4.05%) ⬇️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@bmoffatt
Copy link
Collaborator

I'm not sure about this feature. The feature could cause issues if a current or future version or provided started including built-in support for AWS_LAMBDA_EXEC_WRAPPER. Will forward the proposal on to the product team.

lambda/wrapper.go Outdated Show resolved Hide resolved
@RomainMuller
Copy link
Author

I'm not sure about this feature. The feature could cause issues if a current or future version or provided started including built-in support for AWS_LAMBDA_EXEC_WRAPPER. Will forward the proposal on to the product team.

I would suggest the wrapper script is invoked with the AWS_LAMBDA_EXEC_WRAPPER variable clobbered, so that the child process effectively no longer has it if it's been applied already. If there is an interest in knowing whether the handler was wrapped or not, I'd introduce a new AWS_LAMBDA_EXEC_WRAPPED variable (name to be bikeshed separately) to denote that, and call it a day.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support for AWS_LAMBDA_EXEC_WRAPPER
3 participants