Serverless-application-model: Inline swagger spec inside of template file not working for multiple paths

[talhasavo]

Summary:
Given that a deploy and API gateway stack exist for one path, updating the API gateway inline swagger definition with a second path breaks Cloudformation command execution. In particular, if the first path is a subset of the second one.

Details:
I have an inline swagger spec inside of a template.yaml file.

I run the following command:
aws cloudformation deploy --template-file deploy.yaml --stack-name my-api-stack --capabilities CAPABILITY_IAM

Steps:

1. Command successfully creates a new stack my-api-stack when template has only one path /thing .
2. Now we modify inline swagger spec in the template.yaml to add a second endpoint /thing/{id}/anotherthing. We run the aws command again. Adding the second path /thing/{id}/asset breaks SAM execution.

Error: ResourceStatusReason': 'Invalid Authorizer identifier specified

The error seems a red herring. The authorizer lambda exists and works fine when one path is included.

I also validated my swagger by manually creating the API Gateway endpoint and exporting its spec, and it is identical to what I am providing to SAM.

template:yaml

ApiGatewayApi:
Type: AWS::Serverless::Api
DependsOn: lambda1,lambda2
Properties:
StageName: prod
DefinitionBody:
[Inline Swagger]

I include the following inline swagger spec with two paths:

Inline swagger:

swagger: "2.0"
info:
version: "2017-02-27T20:31:23Z"
title: "test-rb"
basePath: "/prod"
schemes:
- "https"
paths:
/thing:
get:
responses: {}
security:
- auth_this: []
x-amazon-apigateway-integration:
uri: !Sub "arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:lambda1/invocations"
passthroughBehavior: "when_no_match"
httpMethod: "POST"
type: "aws_proxy"
/thing/{id}/anotherthing:
get:
parameters:
- name: "id"
in: "path"
required: true
type: "string"
responses:{}
security:
- auth_this: []
x-amazon-apigateway-integration:
uri: !Sub "arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:lambda2/invocations"
passthroughBehavior: "when_no_match"
httpMethod: "POST"
type: "aws_proxy"
securityDefinitions:
auth_this:
type: "apiKey"
name: "Authorization"
in: "header"
x-amazon-apigateway-authtype: "custom"
x-amazon-apigateway-authorizer:
authorizerResultTtlInSeconds: 300
authorizerUri: !Sub "arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:customauthorizer/invocations"
type: "token"
definitions:
Empty:
type: "object"
title: "Empty Schema"

[jaredhagen]

I've ran into this issue a couple of times. To work around the the issue for now I've been following these steps:

1. Create my resources
2. Create methods on those resources
3. Setup mock integrations for those methods (just select Mock and then click Save)
4. Deploy the api to the stage I'm trying to update.

All of my subsequent stack updates succeed after performing those steps.

[brunomorency]

I get the same error whenever I add a resource/method that uses an existing custom authorizer that deploys with no problems.

[gtaws]

I've gotten similar and the workaround I had to do is to double-quote all my paths in the transformed SAM yaml template.

[dinvlad]

Same problem here. Deploying a new resource that uses an existing custom authorizer (that works well for existing resources) leads to Invalid Authorizer identifier specified

[mgibas]

Same issue here - very annoying when we try to merge our development branch to production :disappointed:

[ghost]

Yep same error for me too. Means SAM is not very useful for production. I am using an external swagger file with AWS::Serverless::Api DefinitionUri and CodePipline for the deployment :(

[dinvlad]

It's actually not that bad, it's just that we have to do a 2-step commit if we need to enable a new resource: once with mock integration for the first method we introduce, and then one with the actual function for that method.

That can actually be organic if you develop for CORS: the first method to always implement is OPTIONS, which is done with mock integration and without authentication anyway.

[brunomorency]

@dinvlad the 2-step commit is really annoying when deploying to production. Rather than just pulling/merging changes to the template then deploying, you'd now need to manually repeat those steps or start keeping multiple versions of the template in the repo and get some script to replay those steps from current production version to newest found in repo.

I've had to maintain db schemas like that and I'd much rather have this bug fixed than having to deal with similar setup with templates :(

Unless you have another way to do it?

[ghost]

We have 5 environments to support, two dev which integrate automatic commits and then manual promotion to test -> uat -> prod. Pushing fake leading commits to all these environments will cause lots of false positive test failures in our automatic test suite.

[dinvlad]

@brunomorency I can relate to that, though I do continuous delivery instead of deployment, so not every change makes it into production.

Also, if you use the OPTIONS method then there's no compromise - you first fully configure this method, and then add additional ones (GET/POST/...) with full configuration.

In addition, making small changes is almost always better than too many things at once..

EDIT: Also as @8357753 mentioned, even continuous deployment could be done in multiple steps if you rely on tests failing for your mock methods. That's what they are for! Don't be afraid of the red ;)

[ghost]

Well sometimes the smallest change for us is adding the config with an authorizer because for some apis we do not use CORs and for other apis we use api gateway in proxy mode. So basically we need to add fake commits which is not optimal. We don't push all changes to production but they do all go to some subset of environments.

[dinvlad]

Fair enough, though pushing into red should not be a problem :)

[ghost]

false positives are friction for us and in any case these are unnecessary builds which will cascade to various other integrations causing more false positives. Sure all this can the solved with various gymnastics but fixing the issue at source seems a better solution.

[dinvlad]

Point taken. I agree that this issue leads to inconsistent/unexpected behavior, which on itself needs a fix.

[kskory]

@sanathkr any update on that? Are you aware of that issue? It's pretty limiting and doesn't have any sensible workaround.

[lafiosca]

I just ran into this as well. Was working on a new API, everything fine, until I added a second endpoint and it blew up. Thankfully Google led me to this issue, which I recalled reading about before and thinking, "Oh this will affect me later."

Thank you @dinvlad for the workaround, but I agree with everyone saying that this needs to be fixed. I don't want to do two consecutive deployments effectively just to add one new GET endpoint.

[lafiosca]

I'll also confirm/reiterate that this only happens when updating an existing API. I was able to delete my entire API and redeploy without an error.

[dinvlad]

I also agree after playing around with it more, that it's pretty annoying. Especially for changing existing routes (e.g. when renaming a path parameter). We not only have to temporarily disable non-OPTIONS methods (if there are OPTIONS at all), but also existing integrations (e.g. I have request validaton code that depends on the Swagger definitions for non-trivial verbs). Doing that is pretty cumbersome. And it also requires downtime in production (even though the underlying change doesn't necessarily).

[sanathkr]

Yes, I am aware of this issue. We have a fix being implemented now. I don't have an ETA for the fix, but it is happening. Will keep this thread posted. Sorry for the annoyance :(

[kskory]

Hey @sanathkr , any updates? Is there any "official" issue for that, where we can track the progress? I don't see anything here: https://github.com/aws/aws-cli/issues .

Thanks

[sanathkr]

@kskory this is pretty much the only Issue tracking this.

[PutziSan]

About 3 Months since last update: Are there any news?

[sanathkr]

This bug is fixed now. Please check and re-open if you have questions.