Serverless-application-model: Error: StageName cannot be updated

[fleeco]

Hello,

This morning we tried to deploy a version of our application and have the following cloudformation error.

Another issue is having the same error and posted about it in the discussion forums. We use SAM to deploy everything so we are sort of at a stand still. Please let me know if you need any further clarification!

https://forums.aws.amazon.com/thread.jspa?messageID=797010#797010

[vikrambhatt]

Hello, looks like there was a regression with a recent deployment. Can you check again if everything is fine? We have reverted our updates.

[fleeco]

Looks good, thanks so much!

[sanathkr]

This should be fixed now.. can you confirm?

[mrybertt]

Hi, we're having the same issue. Yesterday everything was fine, but now it keeps trying to update the stage name and failing to update, then rolls back. The issue went away for a moment maybe an hour ago, but it's back again and we can't get past the deployment. Please help!!

[cheeham51]

it seems it's creating an additional stage "Stage", if I specify 'StageName: Stage' I get 'Stage already exists', if I change it to 'StageName: stage' then I see two stages 'stage' and 'Stage'. Didn't see this yesterday.

[sanathkr]

@mrybertt We have rolled back the change that caused original regression. Can you tell me the region this problem still exists in? When did you first create the stack?

@cheeham51 This additional Stage was a bug that we were fixing as part of the deployment that got rolled back. This will be fixed soon.

[sgruenheit]

Currently we are having this bug now (again) on eu-west-1.

[francis-a]

We're seeing this in eu-west-1 as well. Our StageName is v1 but previously when deploying our generated API Gateway would contain an auto-generated stage named Stage along with our defined v1 stage.

[sgruenheit]

Maybe this is helpful... As we first experienced the error on Friday we deleted our stack and recreated it. I noticed that the stage "Stage" was not created anymore. With that recreated stack updates where possible.
The change that leads to the regression was rolled back then. Now with that version updates are failing again. I deleted the stack again and recreated it and now updates are working again.

[francis-a]

We're trying this now on our development stack right now but we are also hoping to update our production stack today. This stack hasn't been updated in around a week so it hopefully hasn't been affected by this issue however I'm still nervous deploy because deleting and recreating will be a bigger deal in our prod environment.

[ntrivix]

We are having this issue on eu-central (Frakfurt)

[damtur]

We are having the same issue in us-east-1. Please fix/share a workaround asap. Thank you!

[lskrajny]

Same on eu-west-1

[ehault]

can confirm this is still ongoing on eu-west-1

[mwdavisii-zz]

Same issue on us-east-1 using serverless transform and Events.

[sanathkr]

Looking at this more closely now..

[sanathkr]

Looks like a known issue. Here is a workaround to unblock your stack until we fix it on our side.

You need to trigger a redeployment of API resources to unblock the stack. Here is how you do it.

• If you use an external Swagger file, just add a comma, space or an extra character that will change the Swagger's SHA. Deploy your stack now, and it should work.

• If you use an implicit API (the ones defined using Events property on AWS::Serverless::Function), you can add a new dummy API to your Events and redeploy. Example:

RestApiFunction:
     Type: AWS::Serverless::Function
     Properties:
       Handler: index.handler
       Runtime: nodejs4.3
       CodeUri: s3://bucket/code.zip
       Events:
         AddItem:
           Properties:
             Method: get
             Path: /add
           Type: Api
        DummyApiForWorkaround:
           Properties:
             Method: get
             Path: /some-dummy-api
           Type: Api    

Once the deployment is successful, you can revert the workaround and future deployments should succeed.

[yyolk]

@sanathkr thank you so much!!

modifying my swagger (making the deploy assume it changed) was all that was needed.

this was not obvious, thank you again!

[ehault]

@sanathkr can confirm the second workaround worked painlessly for me as well o>

[glynd]

I'm seeing this issue, and using inline swagger.
It looks like adding a ' ' to a comment of the inline data works around the issue.

Annoying that this hasn't been fixed 6 days after reported here

[homingli]

Different than the initial issue opened here, but i see it in the thread so commenting here too.
I see that my SAM/CFN deployments (new stack, today) also has an extra "Stage" stage in addition to the one I defined in my template.

created issue #176

[ghost]

I believe I am seeing a similar issue, I added a comment with more detail to this issue #191 but also adding here for reference.

[sanathkr]

This is fixed now.

[arcsoftech]

In us-east-1 region this problem still exist

[patelman]

I am facing this issue in us-west-2

[sunnypiyush]

any update ?