Deploy: pathmapping - Invalid stage identifier specified.

This is a Bug Report

Description

For bug reports:

• What went wrong? - pathmapping failed, invalid stage identifier
• What did you expect should have happened? - deployment
• What was the config you used?

Pathmapping section

pathmapping:
      Type: AWS::ApiGateway::BasePathMapping
      Properties:
        BasePath: ${self:service}
        DomainName: ${self:custom.domains.${opt:stage, self:provider.stage}}
        RestApiId: 
          Ref: ApiGatewayRestApi
        Stage: ${opt:stage}

Produces this in the serverless-state.json

"resources": {
      "Resources": {
        "pathmapping": {
          "Type": "AWS::ApiGateway::BasePathMapping",
          "Properties": {
            "BasePath": "demolambda",
            "DomainName": "staging-api.<REDACTED>",
            "RestApiId": {
              "Ref": "ApiGatewayRestApi"
            },
            "Stage": "staging"
          }
        }
      }

• What stacktrace or error message from your provider did you see?

Verbose logging of CloudFormation process:

CloudFormation - CREATE_FAILED - AWS::ApiGateway::BasePathMapping - pathmapping

Ending error:

An error occurred while provisioning your stack: pathmapping - Invalid stage identifier specified.

Additional Data

• Serverless Framework Version you’re using: 1.17.0
• Operating System: Linux (Ubuntu 14.04)
• Stack Trace:
• Provider Error messages:

[pmuens]

Closing since this is an old issue and a DependsOn does the trick here.

[ksafranski]

After some digging I figured out that the cause here was basically order of ops on the deploy. Since I was deploying a new stack APIGateway didn’t have a staging stage and it would try to run the pathmapping before the stage existed, hence Invalid Stage.

I saw a couple posts about adding a bogus DependsOn to force it to “wait” but that approach didn’t work so I was left doing 2 deploys; the first without pathmapping in the config to get the stage and Lambda functions created, followed by a second (and then all subsequent deploys) where pathmapping is present and the stage exists.

This doesn’t seem like a major issue since you can pretty easily get around it and once it’s fixed (and the stage exists) it doesn’t happen again, but would be nice to have a better way to get this working on new deploys.