Cannot deploy because: "State Machine Already Exists"

Serverless Framework
1

Hey guys,

I have a a serverless stack that I define on serverless.yml.
That includes lambda functions, step-functions etc etc

I have been able to deploy my entire stack every day for a month now.

Today, all of a sudden, my deploy fails because it says one of my State Machine Already Exists

I understand that it fails because the name is the same. Aren’t resources suppose to be updated?

I’m really confused how this use to work or how do other teams handle deployments if this is something that happens? It’s not acceptable to delete the stack in a production service, in order to redeploy.

Thank you in advance,
Happy to discuss this further

2

This can happen if your CloudFormation stack gets out of sync with the resources in your account. Typically this happens when someone manually modifies a resource in the AWS console. For some resources you can fix the problem by simply correcting the name. For most resources you’ll need to

  1. Comment out the offending setting from your serverless.yml
  2. Deploy your serverless app to remove it from the stack
  3. Check that the resource has been removed from your AWS account
  4. If the resource hasn’t been removed the confirm it’s not longer in the CloudFormation template created by Serverless and repeat from Step 1 until it’s removed.
  5. If you’re 100% certain it’s not in the CloudFormation template but it still exists then manually remove it.
  6. Uncomment the offending setting from your serverless.yml
  7. Deploy your serverless app to create the resource again and add it to the stack
1 Like
3

@buggy, I am replying here because I’m working with @vayias on this project.

For the sake of clarification, what conditions (what types of changes in the AWS console) might trigger this error state? As we move to production it would be really helpful to know what we should never do so that we can avoid needing to deploy an incomplete stack to production to get around this error.

4

@cewing Typically it happens when someone makes a manual change to the stack using the AWS console. If you deploy everything using CloudFormation/Serverless/SAM then you should be ok. The reason using the console can be problematic is that sometimes AWS needs to recreate a resource when you make changes. While the new resource might look like the old resource it will have a different ARN but the CloudFormation stack has the old ARN.

1 Like
5

Thanks for the clear explanation, @buggy