V1.0 error: "Another resource with the same parent already has this name"

Hi all,

I have upgraded from 1.0 RC2 to v1.0 today.

I am using the same yaml file, but on deploy, I get the following error:

Serverless Error ---------------------------------------                                                                                                                                                                                                      
 An error occurred while provisioning your stack: ApiGatewayResourceV1TestsIdVar                                                                                                                                                                            
 - Another resource with the same parent already has                                                                                                                                                                                                        
 this name: {id}.

Can anyone help me troubleshoot this? I have taken a look at the CF update template, but I am not an expert and can’t see what is going wrong.

In my yaml file, I have this

handler: functions/readrow/handler.handler
  - http:
      path: v1/tests/{id}
      method: get
      authorizer: authorization
      integration: lambda
         "application/json": "{\n \"id\": \"$input.params('id')\", \n  \"body\" : $input.json('$'),\n  \"headers\": {\n    #foreach($param in $input.params().header.keySet())\n    \"$param\": \"$util.escapeJavaScript($input.params().header.get($param))\" #if($foreach.hasNext),#end\n\n    #end\n  },\n  \"queryParams\": {\n    #foreach($param in $input.params().querystring.keySet())\n    \"$param\": \"$util.escapeJavaScript($input.params().querystring.get($param))\" #if($foreach.hasNext),#end\n\n    #end\n  },\n  \"pathParams\": {\n    #foreach($param in $input.params().path.keySet())\n    \"$param\": \"$util.escapeJavaScript($input.params().path.get($param))\" #if($foreach.hasNext),#end\n\n    #end\n  }  \n}\n\n"
            - ${self:custom.stages.${opt:stage, self:provider.stage}.vars.URL-Access-Control-Allow-Origin}
            - Content-Type
            - X-Amz-Date
            - Authorization
            - X-Api-Key
            - X-Amz-Security-Token

Any tips on where to look next? what does “Another resource with the same parent already has this name”?

Should I do something to the yaml now that I’m off RC2 and on v1.0?


The problem is we renamed an APIG Cloudformation resource when it contains a variable: https://github.com/serverless/serverless/pull/2201

Basically we now have a resource with a different name but the same path as v1/tests/{id} and because CF creates resources first before deleting old ones there is a clash.

Simple solution: For one deployment rename {id} to {ids}, deploy and then after that deployment you should be able to switch it back.

1 Like

Also I’ll add this to our Changelog because at the moment we don’t have a breaking changes section there.

Thanks for the response!!

I tried the trick of renaming the params, but it then started complaining about siblings having {id}:

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

So my quickest way to get it working was to delete the stack and start again.


I tried the same solution (renaming the parameters), but got the same error. I assume it’s still considered the same route, even though the parameter has a different name.

We can delete/recreate the stack for now (this API isn’t handling live traffic), but I’m interested to know of a workaround that doesn’t involve a lot of downtime.

1 Like

I just changed service name and it works fine.

Got the same problem. My solution is removing the brackets from the URL first. e.g. /photos/{id} => /photos/id. Deploy and add the brackets back. Deploy again.

1 Like