Aws-sam-cli: Command 'sam local start-api' fails when using AWS::Include transform to add a Swagger file for 'DefinitionBody'

[sivarosh]

Description

Command 'sam local start-api' fails when using AWS::Include transform to add a local swagger file for an AWS::Serverless::Api resource under the 'DefinitionBody' property.

This issue occurs with AWS SAM CLI v0.21, and does not occur with v0.19. I believe that this is different from the issue resolved by PR #1410 as the resolution of the 'Fn::Transform' intrinsic appears to cause the issue. Further details below.

Steps to reproduce

Template, Lambda function and Swagger file included at https://gist.github.com/sivarosh/bb7290c16fe15628c8105b842916f454

Install aws-sam-cli v0.21
Run command sam local start-api

Install aws-sam-cli v0.19
Run command sam local start-api

Observed result

v0.21
Error Log : https://gist.github.com/sivarosh/905ce2b49a85b6584cd53580e62888c1#file-v0-21_error-log

v0.19
Successful Log : https://gist.github.com/sivarosh/905ce2b49a85b6584cd53580e62888c1#file-v0-21_error-log

Investigation

In v0.19, when printing the self.resources object under __init__ function of class SamApiProvider in sam_api_provider.py, we see the value:
{'StageName': 'test', 'DefinitionBody': {'Fn::Transform': {'Name': 'AWS::Include', 'Parameters': {'Location': './swagger.yml'}}}}

In v0.21, when printing the self.resources object under __init__ function of class ApiProvider in api_provider.py, we see the value:
{'StageName': 'test', 'DefinitionBody': './swagger.yml'}

In v0.21, it appears that the template dict which is fetched from get_templatefunction of SamBaseProvider class attempts to resolve all intrinsic functions by calling the resolve_template function of class IntrinsicResolver in intrinsic_property_resolver.py.

Under the IntrinsicResolver class, function handle_fn_transform transforms 'DefinitionBody': {'Name': 'AWS::Include', 'Parameters': {'Location': './swagger.yml'}} to 'DefinitionBody': './swagger.yml'

Due to this, when attempting to the _read_from_definition_body function in reader.py invokes parse_aws_include_transform which does not detect an AWS::Include transform as the template snippet has been replaced and the contents of the DefinitionBody are left as ./swagger.yml

Expected result

Expected v0.21 of the SAM CLI to include the local swagger file and create the local API docker container similar to how v0.19 does.

Additional environment details (Ex: Windows, Mac, Amazon Linux etc)

OS: MacOSX
sam --version: SAM CLI, version 0.21.0 (Fails)
sam --version: SAM CLI, version 0.19.0 (Successful)

Please let me know if any additional details are necessary, Thanks!

[sivarosh]

Update: The command sam local start-api fails with SAM CLI v0.22 as well with the similar error log as given by v0.21. Here is the output of the command with the debug flag : https://gist.github.com/sivarosh/905ce2b49a85b6584cd53580e62888c1#file-v0-22_error-log

Commenting out https://github.com/awslabs/aws-sam-cli/blob/develop/samcli/lib/intrinsic_resolver/intrinsic_property_resolver.py#L116 seems to resolve the issue (since the Fn::Transform is not intrinsically resolved).

[paulsson]

I've run into the same problem today. This essentially means if you want to use 'sam local' your openapi definition has to be embedded within your SAM template which is not ideal.
It is much cleaner to keep your openapi definition as a separate file.
sam --version SAM CLI, version 0.22.0
on mac
error:
File "/Users/home/sam-app/v0.22/lib/python3.7/site-packages/samcli/commands/local/lib/swagger/parser.py", line 70, in get_routes paths_dict = self.swagger.get("paths", {}) AttributeError: 'str' object has no attribute 'get'

Sounds like @sivarosh already diagnosed and found the problem.

[healdev]

Hello guys, so I was going to post here asking for help about this issue but good news!
aws-sam-cli version 0.23.0 just got released, I just upgraded my HomeBrew package and the issue appears to have been fixed so fare!
Thanks for the quick resolution :)

[jfuss]

@healdev You beat me to the update!

Closing as it was fixed in v0.23.0