Description:
BinaryMediaTypes is removed from APIGW settings when SAM template is updated and re-deployed
Steps to reproduce the issue:
Globals as follows:Globals:
Api:
BinaryMediaTypes:
- "*~1*"
Package and deploy. Observe Settings section of the new APIGW API. Binary Media Types will have */*
Make some changes to the SAM template. Re-package and re-deploy. Observe Settings section of the APIGW API. Binary Media Types config is empty/missing
Observed result:
Binary Media Types config is empty/missing after SAM template is updated and redeployed
Expected result:
Binary Media Types does not change after stack update.
Output of sam --version: SAM CLI, version 0.6.0
Optional Debug logs:
Add --debug flag to command you are running
https://github.com/awslabs/serverless-application-model/issues/561 might be a better place for this issue. Please feel free to close the inappropriate one.
@abhilash1in We are aware that the package command doesn't support Globals. This is actually an issue on the AWS CLI (SAM CLI shells out to the AWS CLI for sam package and sam deploy.
You can follow the update to the command here
Actually, I think it may be a bit deeper than that. I used the following template to create a stack directly on CloudFormation:
AWSTemplateFormatVersion: '2010-09-09'
Resources:
BinaryMediaTypesAPI:
Type: AWS::ApiGateway::RestApi
Properties:
Name: BinaryMediaTypes Test API
Description: A demo API to demonstrate BinaryMediaTypes bug
BinaryMediaTypes:
- image~1jpeg
Body:
swagger: "2.0"
info:
version: "1.0.1"
title: "BinaryMediaTypes Test API"
paths:
/test1:
get:
produces:
- "application/json"
responses:
"200":
description: "200 response"
x-amazon-apigateway-integration:
uri: "https://requestbin.org/get"
responses:
default:
statusCode: "200"
passthroughBehavior: "when_no_match"
httpMethod: "GET"
type: "http_proxy"
Then _updated_ the stack with another resource /test2. BinaryMediaTypes went blank on APIGW API setting this time as well.
Any thoughts?
I am renaming the issue as a bug in package command to track this appropriately. This is a bug we definitely have in our roadmap to fix.
I do not think losing API Gateway binary media types setting is a bug in sam package command. Also I do not think it is related to globals handling. There clearly is a bug but it is somewhere "deeper". I am coming to this conclusion because the setting is lost even when neither of those features are used.
Having this template:
---
AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'
Description: 'foo'
Parameters:
CodeBucket:
Type: String
Description: 'Deployment package S3 bucket'
CodeKey:
Type: String
Description: 'Deployment package S3 key'
Resources:
FooFunction:
Type: 'AWS::Serverless::Function'
Properties:
Handler: foo-aws
Runtime: go1.x
CodeUri:
Bucket: !Ref CodeBucket
Key: !Ref CodeKey
FunctionName: foo
MemorySize: 448
Timeout: 20
Policies:
- AWSLambdaBasicExecutionRole
Events:
Api:
Type: Api
Properties:
RestApiId: !Ref FooApi
Method: ANY
Path: /foo
FooApi:
Type: 'AWS::Serverless::Api'
Properties:
StageName: Prod
EndpointConfiguration: REGIONAL
BinaryMediaTypes:
- '*~1*' # this means '*/*'
If I deploy this template with:
aws cloudformation deploy \
--template-file foo.yaml \
--stack-name foo \
--capabilities CAPABILITY_IAM \
--parameter-overrides "CodeBucket=foo" "CodeKey=foo.zip"
At this point the API is set to "all binary mode". Binary responses are successfully received from my API.
Then I make some change to FooApi and re-deploy with the same command. As a result the BinaryMediaTypes setting is lost and responses are base64 encoded instead of being binary. Note that this did not involve running sam package or using globals.
As mentioned by @jfuss, this _may_ be an issue with the AWS CLI or even CloudFormation itself.
Does not resolve all globals, but CodeUri is resolved as of : https://github.com/awslabs/aws-sam-cli/pull/1766
The original issue here was a bug that was fixed in 1.13.0 in the SAM Spec: https://github.com/awslabs/serverless-application-model/issues/561#issuecomment-515580820
sam package will not package values found in Global.
Closing
Most helpful comment
I am renaming the issue as a bug in
packagecommand to track this appropriately. This is a bug we definitely have in our roadmap to fix.