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?