Actual Payload Shared in Step Functions Console On Function Error about aws-lambda-power-tuning HOT 8 CLOSED

Apologies, I didn't fully understand the issue at first :)

Your're correct, we should also add a toggle for the executor function to avoid logging the invocation payload.

Happy to accept a PR 🚀

from aws-lambda-power-tuning.

@rrhodes would it make more sense as an execution parameter (at runtime) or as a CloudFormation parameter (at deploy time)? I don't have a strong opinion, but it sounds like it would be more flexible as an execution parameter, so you can use the same deployment for both use cases.

from aws-lambda-power-tuning.

it sounds like it would be more flexible as an execution parameter, so you can use the same deployment for both use cases.

An execution parameter I agree would make more sense, yep. 👍🏻

from aws-lambda-power-tuning.

Super 😄

Based on the naming conventions used so far, I'd imagine a parameter such as disablePayloadLogs (boolean) or something similar.

And please note that the same happens here (series invocations) and here (pre/post-processor invocations).

from aws-lambda-power-tuning.

Hey @alexcasalboni, that should be PR #213 ready for review implementing the agreed approach. Feedback welcome!

from aws-lambda-power-tuning.

Hi @rrhodes, thanks for reaching out!

Have you considered using the payloadS3 input parameter? That allows you to provide an S3 bucket/key that contains the input payload (instead of providing it directly to Step Functions).

This should solve the more common case (no error).

In case of errors, I'd suggest to just avoid dumping the credentials into your logs (or somehow encrypt it before dumping it).

from aws-lambda-power-tuning.

Thanks for the prompt reply @alexcasalboni! I'll take a look into this and try to have a PR up next week for review. 🙂

from aws-lambda-power-tuning.

Thanks @alexcasalboni! The name sounds good to me, and thanks for the head's up on the other areas to review. 😊

from aws-lambda-power-tuning.