This will fix a small issue with two separate step functions: hv-vpp-ti-sync-wrds-location-db and db_dump_to_s3. The SystemsManager.SendCommand step of these state machines kicks off a .sh script and is configured to wait indefinitely until it either receives a TaskSuccess or TaskFailure call from the .sh script. We must have configured the permission for the TaskSuccess call, since that works. But whenever the .sh script fails, the step function remains in the "Running" state indefinitely until I manually terminate it. I dug in today and found this error being thrown by the .sh scripts:
An error occurred (AccessDeniedException) when calling the SendTaskFailure operation: User: arn:aws:sts::526904826677:assumed-role/hv-vpp-ti-us-east-1-data-ingest/i-071debe18039c91fa is not authorized to perform: states:SendTaskFailure on resource: arn:aws:states:us-east-1:526904826677:stateMachine:hv-vpp-ti-restore-db-from-s3 because no identity-based policy allows the states:SendTaskFailure action
This will fix a small issue with two separate step functions: hv-vpp-ti-sync-wrds-location-db and db_dump_to_s3. The SystemsManager.SendCommand step of these state machines kicks off a
.shscript and is configured to wait indefinitely until it either receives aTaskSuccessorTaskFailurecall from the.shscript. We must have configured the permission for theTaskSuccesscall, since that works. But whenever the.shscript fails, the step function remains in the "Running" state indefinitely until I manually terminate it. I dug in today and found this error being thrown by the.shscripts:An error occurred (AccessDeniedException) when calling the SendTaskFailure operation: User: arn:aws:sts::526904826677:assumed-role/hv-vpp-ti-us-east-1-data-ingest/i-071debe18039c91fa is not authorized to perform: states:SendTaskFailure on resource: arn:aws:states:us-east-1:526904826677:stateMachine:hv-vpp-ti-restore-db-from-s3 because no identity-based policy allows the states:SendTaskFailure action