能否在不改变原有结构的前提下为Step Functions的InputPath添加新键值对？

Great question! I totally get why you want to avoid cluttering your state machine with extra Pass states—keeping workflows concise and maintainable is crucial. Let’s walk through a clean, built-in way to achieve exactly what you need, right within the Lambda invocation state’s configuration.

Use the Object Spread Syntax in Parameters #

Step Functions supports a handy JSON Path extension: the object spread operator (...$), which lets you expand all key-value pairs from your original input and merge them with new properties directly in the Parameters field—no nesting, no extra states required.

Here’s how to configure it for your example:

{
  "Type": "Task",
  "Resource": "arn:aws:lambda:REGION:ACCOUNT_ID:function:YOUR_LAMBDA_FUNCTION",
  "InputPath": "$",
  "Parameters": {
    "key3": "value3",
    "...$": "$"
  },
  "End": true
}

What this does: #

• The "...$": "$" line expands every key-value pair from your original input ({ "key1": "value1", "key2": "value2" }) into the Parameters object.
• Your new key3: "value3" is added alongside these existing keys.
• The final input passed to Lambda will be exactly what you want:

  { "key1": "value1", "key2": "value2", "key3": "value3" }
  

Handling Dynamic Values #

If your new property needs to pull a value from the existing input (instead of a static string), use the .$ suffix syntax just like you would for other dynamic parameters:

"Parameters": {
  "key3.$": "$.someExistingValue", // Pulls value from original input
  "...$": "$"
}

Key Note on Overrides #

If your original input has a key with the same name as your new property, the order in Parameters matters:

• If you define the new property before the spread operator (...$), the original input’s key will override the new one.
• If you define the new property after the spread operator, the new property will override the original key.

This gives you full control over which value takes precedence if there’s a conflict.

内容的提问来源于stack exchange，提问作者pdanchenko