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.

Is any solution available?

Ran into this issue today. Crazy this is a four-year-old bug

That works for me:

1. Comment out function definition in serverless.yml
2. serverless deploy
3. Uncomment function definition in serverless.yml
4. serverelss deploy

Profit!

For maximum breakage best done with a live production environment that is hooked to a domain. Enjoy! 😋

if you have your routes like,

anything/{user_id}/getsomething anything/{user_id}/somethingelse

make them like,

anything/getsomething/{user_id} anything/somethingelse/{user_id}

if you want to use different methods on the same rout,

use ‘any’ as a method

• http: path: anything/somethingelse/{user_id} method: ‘any’

then inside your handler

use

switch (event.httpMethod) { case ‘GET’: // case ‘POST’: //

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…

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?

What’s the serverless team’s status on this?

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.

FWIW, I just ran into this today. Very frustrating to have to take the function down.

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}

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?

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

Have been watching this issue for some time because I ran into it a while back. Ran into it again today. Not sure how this hasn’t been fixed yet… it’s been open a long time and the solutions offered are not viable for live production systems. Would love to see this addressed asap. Pretty please…

For me the issue was that the path parameters that are in the same place in the path should have the same names. E.g., if you have the paths /user/{userId} and the path /user/{accountId}/{userId} it throws this error. Changing the latter path to /user/{userId}/{accountId} fixes the error.

See this answer https://github.com/serverless/serverless/issues/1909#issuecomment-282899881

It has been solved!

That’s what I’m gonna say some magical day in the future, because right now it’s still an issue 👎🏼

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.

We ran into this issue today. Having to avoid renaming a path variable because it would be too disruptive is a real shame.

Just ran into this, would be nice if serverless recognized this and did the workaround for you.

Same issue here. But what I would like to understand is if this is a problem with Serverless framework or just Cloudformation/Apigateway? Can someone make some light on this one since it has been going on since 2017.

EDIT: I just spoke with the AWS support and they confirm me that this is an issue on their side. Cloudformation will create a new resource before deleting the one you are trying to change, thus the overlapping of paths

I suspect a workaround/fix for this is tricky in that it smells more like a cloudformation issue than a serverless one…

@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.

Nice I will take a look at the package! Kinda goes against the idea of serverless where each function is deployed and scaled separately as you now use 1 lambda for your entire application, but these kind of bugs make it almost impossible to use serverless in a good way

That works for me:

1. Comment out function definition in serverless.yml
2. serverless deploy
3. Uncomment function definition in serverless.yml
4. serverelss deploy

Profit!

@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.

@Ehbraheem @WyllianNeo please read https://github.com/serverless/serverless/issues/3785#issuecomment-1873449838

Happened to me today as well.

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}

To get around this I deployed a second copy of my API with --stage temp but pointed it at the existing production database, pointed production services at the temporary deployment and then had the freedom to modify production without downtime.

Far from ideal but works in case anyone is really stuck.

Obviously steps may vary depending on various criteria. For example with my temporary service I did not deploy all non http functions/handlers, and left the production service handling those. The temporary service simply handled the http part so i could remove them from production periodically.

1. deploy temp service pointing at production database (don’t forget iam access)
2. point other services at temporary api url or update custom domain to point at temporary service
3. delete route /{proxy+} from production service and deploy
4. add route /{id} (or whatever your clashing sibling route(s) may be) to production and deploy
5. point other services at production api url or update custom domain to point at production service
6. remove temporary service

Very cumbersome but did allow me to get done what I needed.

@MatteoGioioso Unfortunately, to my best understanding, this is an issue on AWS/APIGW side

Encountered this error on my end. Do you have solution for this. What I tried is.

1. Deploy, delete and redeploy the SLS, which didn’t solved the issue
2. Comment out serverless.yml, deploy, uncomment then deploy, still didn’t solved the issue.
3. No paths are the same now, basically changed all the paths for each method but still encountering this issue. Sh*tty CF

Ran into this today also, not keen on tearing down production resources just to rebuild them with the new path variable name

@josephnaber no, cloudformation considers that a conflicting path. Please read the previous comments. As an aside, your paths should probably look like /notes/{noteid} /entities/{entityid}/notes/{noteid}

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.

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.