serverless: [Critical Bug] `sls deploy` does not create API endpoints in `Stages` section of Amazon API Gateway

Serverless Framework Version:
1.0.0-alpha.2
Operating System:

image

Expected Behavior:

API endpoints described/configured in serverless.yaml file being deployed and visible in Stages section on AWS console (Amazon API Gateway)

Actual Behavior:

They are not visible and are not being deployed there as you can see below:

image

leads to:

image

which leads to:

image

Cloudformation and sls deploy does not throw any errors

I would consider this as critical bug/issue. @pmuens ? @eahefnawy ?

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 26 (24 by maintainers)

Commits related to this issue

Most upvoted comments

The problem is because the APIGateway:Deployment action DependsOn your first APIGateway:Method creation, which will typically only happen on your first deploy. That condition should be removed.

I immediately ran into problems once I’d adding more than one function which is what send me down this path.

There is a quick fix to the race condition, where you can add all the method resources to the deployments DependsOn option. This will help when setting up all the functions, but does not solve the problem when removing functions.

The stage still keeps endpoints around for removed functions.

I’ve had a quick conversation with one of the guys at the APIGateway team and he’s passed on the query to the cloudformation team.

https://twitter.com/sapessi/status/760500226247360512

Will see what the chat is

Right I’ve done some more digging and the depends on just masks a race condition that exists if you have many functions. A few thoughts.

There needs to be a WaitCondition triggered when all the methods have been created which then runs the deploy.

There also needs to be something that checks for method removal and deploys.

Deploy keys need to be unique to force a new deployment.

    const deploymentTemplate = `
      {
        "Type" : "AWS::ApiGateway::Deployment",
        "DependsOn" : "${this.methodDep}",
        "Properties" : {
          "RestApiId" : { "Ref": "RestApiApigEvent" },
          "StageName" : "${this.options.stage}",
          "Description" : "${this.options.stage} created at ${new Date()}"
        }
      }
    `;

    var uniqueDeploymentObject = {};

    uniqueDeploymentObject['DeploymentApigEvent' + (new Date()).getTime()] = JSON.parse(deploymentTemplate);

    const newDeploymentObject = uniqueDeploymentObject;

As this is fixed as far as we can fix it I think we can close this specific issue. We’ll still have to talk to AWS to make sure the removal happens in a clean way, but we can’t really do anything about that yet.

Yup, talking to @domdivakaruni from AWS soon to find a way to resolve this. I’m not completely sure yet if there is something we need to do differently in our Cloudformation template, or if its a bug in AWS. Thanks for all your research @wedgybo so far on this, very helpful