aws-stepfunctions-tasks: Confusion between RunLambdaTask and InvokeFunction

There are now two similar-looking constructs in aws-stepfunctions-tasks pertaining to Lambda tasks, and it’s not clear which one to use.

Users who are used to historical Step Functions patterns and want things to easily work should use InvokeFunction. However, there are some corner cases where people want special behavior (e.g., asynchronous execution) who like to use RunLambdaTask.

If you mix these up, be prepared to spend a lot of time debugging. @ccfife and I spent the afternoon scratching our heads to figure out, when we accidentally used RunLambdaTask, why the event payload being sent to our Lambda function Tasks was an empty event.

Let’s do something to disambiguate these and make clear when a user should use one or the other.

[sacag]

@shivlaks - finally got it to work with the below code: new RunLambdaTask(props.PostToAPILambda,new RunLambdaTaskProps { Payload = new Dictionary<string, object>() { { "input", Context.StringAt("$$.Execution.Input") } } })

[sacag]

@shivlaks, @rix0rrr - I am seeing more issues with RunLambdaTask: below is the code which works with InvokeFunction…$.Payload has my model in json string

 Task = new InvokeFunction(lambdaFunction),                
                InputPath = "$.Payload",
                ResultPath = "$.lambdaResult",
                OutputPath = "$.lambdaResult"

The same code when using RunLambdaTask…not sure how to access $.Payload in the Payload property, so that it can be passed over to the Lambda function? This is what I have. This passes NULL to my lambda function

Task = new RunLambdaTask(lambdaFunction,
                            new RunLambdaTaskProps 
{ Payload = new Dictionary<string, object>() { { "lambdaResult", Context.StringAt("$$.Payload") } } }),
                InputPath = "$.Payload",
                ResultPath = "$.lambdaResult",
                OutputPath = "$.lambdaResult"

When I do Context.StringAt(…) in RunLambdaTask, i think it takes the execution’s input and not the task input…i think, maybe there is another way to access the TaskState input?
@otterley - wondering if you were able to figure this out?