run SSM from step functions

I am trying to run SSM commands from step functions and am able to run the commands. But it is not able to capture the response correctly. Even though the command fails with some error, the step succeeds in step function. I am using the following definition.

{
  "Comment": "Copy File to S3 State Machine",
  "StartAt": "SendCommand",
  "States": {
    "SendCommand": {
      "Type": "Task",
      "Resource": "arn:aws:states:::aws-sdk:ssm:sendCommand",
      "Parameters": {
        "DocumentName": "AWS-RunShellScript",
        "Parameters": {
          "commands": [
            "sudo -u muser aws s3 mv s3://dev-etl/shared-data/temp1/ s3://dev-etl/temp/ --recursive --exclude '*' --include 'abc.sql' "
          ]
        },
        "Targets": [
          {
            "Key": "InstanceIds",
            "Values": [
              "i-sampleinstanceid"
            ]
          }
        ]
      },
      "End": true
    }
  }
}

I am trying to wait for the event but am not able to correctly create the definition to capture the event response and make the step function succeed or fail properly. Any solutions would be appreciated.

The SendCommand API Action starts a command invocation with SSM which it then completes asynchronously. When you call this from a Step Functions workflow using the default Request Response Service Integration Pattern, the workflow will make that call on your behalf and receive the API response, then continue.

If you want to have the workflow wait for completion, capture the result, then proceed based on the result, you will need to enhance the workflow. There are a couple ways you can do this.

First, would be to use the Callback (.waitForTaskToken) Service Integration Pattern. With this pattern, Step Functions will pause after making the call to your target API Action and wait until the agent processing the task makes a call back to Step Functions to continue. You can see a complete example of doing this with SSM here. This approach has the advantage of fewer steps in your workflow, but creates coupling with the task you are executing (which may or may not be what you want).

Second, would be to use the Job Poller pattern. With this pattern, you add steps in your workflow to take the identifiers returned from your first call and then make periodic calls to another API Action to monitor would use for this purpose. Workflow Studio can help you here, as you can drag and drop that pattern into your workflow from the Patterns tab (see image below). And if this is something you expect to do often, it can be handy to wrap this into a separate state machine that you can then call from other workflows using the Optimized Service Integration for Step Functions itself, which supports the Run a Job (.sync) Service Integration Pattern (where the asynchronous to synchronous mapping is managed by Step Functions). You can see an example of such a utility state machine here for Glue Crawlers, but the pattern is broadly applicable. The advantage of the Job Poller approach is that you don't need to couple the implementation on the SSM side, which I suspect will be best for your case.