You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The cfn.LambdaWrap convenience method is very useful for creating the cfn.Response that is written back to the cloudformation s3 bucket. Unfortunately, there doesn't seem to be a way of setting the NoEcho bool on the cfn.Response when using cfn.LambdaWrap.
Describe the solution you'd like
Perhaps adding a noEcho bool to the returned tuple from the CustomResourceFunction, and then checking for that value in lambdaWrapWithClient. Not ideal because that is a breaking change.
Another option would be to have CustomResourceFunction return a Response object, instead of a tuple with the physicalResourceId and the data map. That would allow the user to populate Data,PhysicalResourceId, and NoEcho themselves, and have the boilerplate fill in the required values after. Again, this would be a breaking change.
The 2 options above would work with new function definitions of LambdaWrap, in order to maintain backwards compatibility.
Describe alternatives you've considered
The current work around is to copy the boilerplate code, and craft the Response myself.
Additional context
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
The
cfn.LambdaWrap
convenience method is very useful for creating thecfn.Response
that is written back to the cloudformation s3 bucket. Unfortunately, there doesn't seem to be a way of setting the NoEcho bool on thecfn.Response
when usingcfn.LambdaWrap
.Describe the solution you'd like
Perhaps adding a
noEcho
bool to the returned tuple from theCustomResourceFunction
, and then checking for that value inlambdaWrapWithClient
. Not ideal because that is a breaking change.Another option would be to have
CustomResourceFunction
return a Response object, instead of a tuple with the physicalResourceId and the data map. That would allow the user to populate Data,PhysicalResourceId, and NoEcho themselves, and have the boilerplate fill in the required values after. Again, this would be a breaking change.The 2 options above would work with new function definitions of
LambdaWrap
, in order to maintain backwards compatibility.Describe alternatives you've considered
The current work around is to copy the boilerplate code, and craft the Response myself.
Additional context
The text was updated successfully, but these errors were encountered: