AWS API Gateway: Error when renaming path variable

[matheusvellone]

This is a Bug Report

Description

Tried to rename a path variable and got the error.
Deployed a service with the following yml config:

service: aws-nodejs

provider:
    name: aws
    runtime: nodejs6.10

functions:
    hello:
        handler: handler.hello
        events:
            - http:
                path: /{pathvar}
                method: put

Then changed it to

service: aws-nodejs

provider:
    name: aws
    runtime: nodejs6.10

functions:
    hello:
        handler: handler.hello
        events:
            - http:
                path: /{pathVar} # Changed this variable
                method: put

Then tried to redeploy the service to update the variable name and got the error.

For bug reports:

• What went wrong?
  An error occurred while provisioning your stack: ApiGatewayResourcePathvarVar. A sibling ({pathvar}) of this resource already has a variable path part -- only one is allowed.
• What did you expect should have happened?
  Expected the service to deploy the new route over the old one. Renaming the path variable from pathvar to pathVar.
• What stacktrace or error message from your provider did you see? An error occurred while provisioning your stack: ApiGatewayResourcePathvarVar - A sibling ({pathvar}) of this resource already has a variable path part -- only one is allowed

Similar or dependent issues:

• Multiple Path Vars for same function #3075

Additional Data

• Serverless Framework Version you're using: 1.15.3
• Operating System: WIN 10
• Provider Error messages: An error occurred while provisioning your stack: ApiGatewayResourcePathvarVar. A sibling ({pathvar}) of this resource already has a variable path part -- only one is allowed.

If more information is needed, just let me know.

[Tlapi]

I have the same issue when removing variable from path.

Old yml config:

load:
    handler: handler.load
    events:
      - http:
          path: load/{key}/{account}/{id}
          method: get
          cors: true
          integration: lambda
          request:
            parameters:
              paths:
                id: true
                key: true
                account: true

Updated yml:

load:
    handler: handler.load
    events:
      - http:
          path: load/{key}/{id}
          method: get
          cors: true
          integration: lambda
          request:
            parameters:
              paths:
                id: true
                key: true

Error:
An error occurred while provisioning your stack: ApiGatewayResourceLoadKeyVarIdVar - A sibling ({account}) of this resource already has a variable path part -- only one is allowed.

[HyperBrain]

It seems that CF first tries to add the new resource, and then to remove the old resource. This leads to an intermediate state where both resources will exist, which is of course not possible, because they interfere with each other.

Just some unordered thoughts to get a discussion running:

• Using dependencies is no option, as the final stack should only contain the new path resource
• Maybe creating an intermediate changeset (to remove the old resource) could be used before updating the stack. This would mean to add a local resource precheck and handling to Serverless that identifies if we run into this condition.
• Is there any other way but dependencies to tell CF about the needed order?

[pettyalex]

Workaround for now:
Comment out the function from your serverless.yml, run a full deployment. This will delete the API gateway endpoint entirely, and then you can uncomment the function and run a deployment to deploy the new function with the new pathParam.

[deQuota]

@pettyalex
thanks, It was quite a relief.
Someone know why serverless removes the older at last instead of doing it first,
Is that because someone may be using the older versions at the deployment time of new one

[kristianperkins]

I'm using the workaround suggested by @pettyalex but unfortunately makes me hit another issue where cloudformation stalls in the state UPDATE_COMPLETE_CLEANUP_IN_PROGRESS where it is taking a long time to delete lambdas inside VPCs: https://forum.serverless.com/t/very-long-delay-when-doing-sls-remove-of-lambda-in-a-vpc/2535

[peterecofit]

Thing is, deleting the API and then creating it again changes the URL endpoint. This is pretty destructive, is there a less destructive solution to this?

[atheiman]

Im new to serverless framework, but found workaround that worked for me and didnt result in a change to the endpoint hostname. It might still cause a short outage for your service because it seems the resource paths are not responding correctly, but that might be acceptable considering you are changing the paths. Its better than deleting the entire api endpoint tho.

This workaround changes the path from /{one}/{two}/{proxy+} to /{one}/{two}/{three}/{proxy+}.

1. serverless.yml (initial state): path: /{one}/{two}/{proxy+}
2. serverless.yml: path: /
3. sls deploy
4. sls deploy again
   not sure if this was necessary.. curl http://<api>/ was now working but curl http://<api>/arg1/arg2/the/rest was also still was working even tho I had removed it from serverless.yml. maybe i just needed to wait longer than a few minutes for an update?
5. serverless.yml (final state): path: /{one}/{two}/{three}/{proxy+}
6. sls deploy
7. sls deploy again
   not sure if this was necessary but curl http://<api>/arg1/arg2/arg3/the/rest was now working but curl http://<api>/ was also still was working even tho I had removed it from serverless.yml. maybe i just needed to wait longer than a few minutes for an update?

It seems there is something very wrong with the CloudFormation updates to ApiGatewayResourcePathvarVar resources, but I could see the argument that this is not that big of an issue because changing path variables is not something that will be done in production very often. I think api developers would be better off adding new endpoints and deprecating old ones (tho maybe I am misunderstanding the workflow here, like I said Im new to this framework). I only ran into this issue making a simple example serverless app.

[simlu]

So the accepted solution here requires you to take down the routes. Not really acceptable if you are just changing marginal things (e.g. making path parameter required) and the route are live in production and used heavily. Bleeding edge is bleeding edge....

[MacMcIrish]

This can be a problem for when a route has been deleted, and a new route with a variable in the same part of the path is now being added.
IE:
some/{path}
# some/{path} (removing the url from API gateway)
some/{path2} (fails to deploy)

It looks to me that this has something to do with the way stage works, and the workaround is still to destroy the entire API gateway and rebuild.

[FBloembergen]

Any news on this issue? We have trouble as well and undeploying the entire api/path is not really acceptable since it runs live in production.
Is canary maybe a solution to make it a more smooth transition?

update: Nevermind, it looks like its not a problem with Serverless, its in cloudformation. When you change your path in ApiGateway it creates the new resources and then directly starts the deployment.
Including your old path/methods.
After the deployment it starts the cleanup and removes your old resources.

[avi2021]

Is any solution available?

[laurensV]

So the accepted solution here requires you to take down the routes. Not really acceptable if you are just changing marginal things (e.g. making path parameter required) and the route are live in production and used heavily. Bleeding edge is bleeding edge....

I agree, this should have way higher priority and should have been fixed a long time ago. This issue is close to being 2.5 years old and this bug can be a real showstopper for some applications.

[simlu]

@laurensV We stopped using path parameter entirely and route and validate in application logic with a single resolver route (using lambda-serverless-api on npm, disclaimer I'm the author).

There are still problems with rouge routes in stage as @MacMcIrish described, but if you do a drift detection in cf after a deploy the next deploy seems to be removing the stage path.

Not ideal but at least we don't need to remove and redeploy anymore.

[pajohns]

I experienced this error, but the cause of my problem was actually legitimate hence why commenting out the yaml, deploy, uncomment and redeploy wasn't working. I had two functions that I was trying to deploy with the following paths.

/user-accounts/{id}
/user-accounts/{userAccountId}/ledger-accounts/{ledgerAccountId}

This wasn't working given that /user-accounts/{id} was conflicting with /user-accounts/{userAccountId}. The fix for me was changing this to

/user-accounts/{userAccountId}
/user-accounts/{userAccountId}/ledger-accounts/{ledgerAccountId}

[jdgcj]

We're experiencing the same.

[AndieKL]

Experiencing this issue. 5 years now for this issue. What can we do to encourage a resolution?

[tomchiverton]

Yup, happened again today when I changed the httpApi.path from /api/attribute/{attribute_id} to /api/attribute/{attributeS_id} in a method: get and method: post.

Had to force deploy without either to work around it. Good job wasn't our live stack...

[sebelga]

Happening to me today... Not sure I understand why 2 different route method (PUT, POST) fight for the same route params name...

Had to use the following names, which is far from ideal

# param1 has different meaning based on the method
POST /myroute/{param1}/{param2}
PUT /myroute/{param1}

[trico-tillster]

Happened to me today as well.

[hepifish]

And today :)

[AlexanderAvazkhodjayev]

any updates on this?

[meJevin]

Multi billion dollar company right there

[sh4hids]

And today too 😄

[ubershloder]

still no luck?

[samirkape]

6 year old bug

[gkuga]

This bug still remains. How can I help fix it?

[Joel-16]

Just happened to me now

[vitorsilvalima]

Just happened to me today too

[hitsumaru]

This bug still out there. How can we caught him?

[gndelia]

Same issue here 😢

[pkit]

That's how CloudFormation works, cool down, cannot be solved in serverless.
Temporarily removing and re-adding the affected route is the only solution.

I ended up switching to the AWS CDK for serverless APIs. :) It's a great replacement. I really appreciate serverless filling the gap for so long though. Thank you!

AWS CDK uses CloudFormation underneath, i.e. the behavior will be the same.

[ghost]

Still having the same problem today, any updates on this? Maybe some news from AWS? Since from what I understand this is an AWS CloudFormation issue.

[Ehbraheem]

Same problem today

[WyllianNeo]

Yeah, faced this error some minutes ago, like @Ehbraheem

[pkit]

@Ehbraheem @WyllianNeo please read #3785 (comment)

[tomchiverton]

This issue should be closed and locked as unfixable -- †øღ Sent from a super computer that fits in my pocket and is connected to the sum total of all human knowledge

…

On 27 February 2024 17:11:54 GMT, Constantine Peresypkin ***@***.***> wrote: @Ehbraheem @WyllianNeo please read #3785 (comment) -- Reply to this email directly or view it on GitHub: #3785 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[JamesWilson19947]

Also happened to me, please fix 🙏

[VijethKashyapTR]

Facing the same error, please have a fix serverless!!

[tomchiverton]

This issue should be closed and locked as unfixable as it's a CloudFormation problem.

Reporters should be moaning at AWS