Conditionals, Refs, etc. in template yaml don't appear to be evaluated

[tedbrandston]

I expected the conditional here to produce "some value" when run with sam local and the EnvType parameter unset or set to "test". Instead it produced no value. My function sees the environment variable "TABLE" as holding an empty string.

There's an error in the output of sam local start-api when using this template:
ERROR: json: cannot unmarshal array into Go struct field AWSServerlessFunction_FunctionEnvironment.Variables of type string. Converting the array style !Equals and !If to their Equals: and If: equivalents merely changes the error to 'cannot unmarshal object into...'

[sanathkr]

Unfortunately SAM Local does not evaluate CloudFormation conditionals. CFN intrinsic functions has a lot of dense logic which is not practical to evaluate in its entirety. You can instead override the value of this param with a --env-vars TABLE=foo flag.

[tedbrandston]

And there are no plans to support any intrinsic functions in the future?

[sanathkr]

No, we do have plans. In fact, I am thinking of adding full support for a small subset of intrinsic functions. Today we have a half-baked support for many intrinsics.

Can you explain your use case further? What do you think would be good set of intrinsics to support?

[tedbrandston]

For the use case described above I'm satisfied with your recommendation of using --env-vars. I might also just handle it in the python, triggered off of the AWS_SAM_LOCAL env var.

However, I tried using those intrinsic functions to toggle between "bundle.zip" and "." for #195, and that didn't work. I believe that just supporting the Condition Functions would let me get that to work as expected, but as I said in that ticket I'm happy with a different solution if there's a better one.

I'll close this, since I have no use case that requires this as a solution and you've answered my question of "is this supposed to work?" Thank you for your help!

[jhovell]

Should this caveat be mentioned in the documentation? It took a lot of searching to hunt down this closed Git issue. Maybe mention under Project Status or a new section on limitations/caveats?

https://github.com/awslabs/aws-sam-local/#project-status

[jhovell]

One other note: the workaround as described here is out of date/incorrect. Need to override all environment variables via a file. I tested that you can override just some of the variables, you do not need to specify them all

https://github.com/awslabs/aws-sam-local#environment-variable-file

[bedge]

@sanathkr
Here's a case you need conditionals for.

I need to deploy a lambda fn to 2 different AWS accounts. In one, I need to specify a VpcConfig, in the other, I don't/can't.

Simply replacing the values with empty strings in the latter case won't work. The entire block needs to be removed:

VpcConfig:
  SecurityGroupIds:
    - stagevpc-xx
  SubnetIds:
    - mgmtsubnet-us-east-1a

[estyh]

This just got me. Took a while to figure out what the problem was! No errors, just silently blanking out my environment vars. After I found this, I created an env.json file to use just for local dev, but this should be in big letters in the documentation somewhere (or better yet, fixed!)

[kpx-dev]

oh my god, same thing happened to me just now, took me hours to figure out why, the error message was not very helpful:

APIError: 500 Server Error: Internal Server Error ("json: cannot unmarshal array into Go struct field ContainerConfigWrapper.Cmd of type string")

I was using !Ref everywhere inside my sam template (https://github.com/networth-app/networth/blob/ae41b8ae70e3b2400078d90392d7651db2a7c9d8/api/template.yml#L33)

I was getting 2018-08-21 15:47:50 Invoking {u'Ref': u'AppName'} (go1.x) when doing sam local start-api. So my current workaround now is to remove all !Ref and just hardcode config val for local template.

[JasonHenriksen]

This is the most horrible mis-feature I have heard of in a long long time.

I've spent TWO HOURS trying to figure out why references don't work. Only to find out that because I'm testing locally they were never going to work anyway?

Testing locally is uselessly and completely broken if things like !Ref don't work.

If you're not going to support this, please take away the pretense of support for local testing. It is a lie.

[jfuss]

@JasonHenriksen I apologize on behalf of the team for the poor experience you have had. Can you explain what you are trying to do further and what version of SAM CLI you are using?

For context, SAM CLI does support !Refs of Parameters but not runtime computed properties. What I mean by "runtime computed properties" is, we don't have a way to produce arns, names, etc of resources because those are defined after the resource is created. Locally these don't exist and why we don't support getting these kinds of values from resources. Please keep in mind that supporting this locally, means the team would need to re-implement a lot of what CloudFormation does locally (which in many cases just doesn't scale well and we will always be behind new features). With that said, we still want to enable testing locally and ideally provide another way for customers to accomplish what they need. For example, we allow overriding Env Vars defined in the template or passing in values for Parameters. Understanding what you are doing deeper, will help in achieving this and close any gaps we might have.

Happy to talk directly with you on Slack, as well. Could be easier than going back and forth on through an issue.

[JasonHenriksen]

@jfuss So specifically, I wanted to use SAM to allocate a bucket, and pass the name of the bucket as needed by the aws-sdk into a node lambda. I was only testing locally and I tried every possible example to do that I could find to do that. I spent literally hours trying to do this, and I didn't bother to try it on the cloud, because my thinking was "if it doesn't work locally what's the point of trying it on the server."

Really, the promise of local testing is that it does replicate what cloudformation does on a local box. Especially for brand new users like me who are just learning this stuff. I have zero experience with cloudformation. I am starting out brand new with SAM, and from my perspective, every single example of how to pass template variables around just mysteriously does not work.

So here are my asks:

1. Replicate what cloudformation does with those names. It's a big lift and I understand if you can't do it. But if you can't do this one you MUST do the next one

2. PROVIDE A REAL ERROR MESSAGE! If you know that an intrinsic function will work in the cloud, but not work locally, then you must provide a local implementation of the call that writes to the console saying, "We're sorry. That function will work on the cloud, but will not work on local environments". That one error message would have saved me hours and hours of time and would explain to new users what is going on. I could have googled for that error message to find our about the lack of intrinsic function support. As it is, the call the the function fails in complete silence and I have no idea why the examples don't work.

The idea of local run is a huge win when it works. I am thankful to your team for putting in the time and effort. However, SAM and CloudFormation are your API. If there are parts of that API that you are leaving unimplemented, you really really need to provide an error message saying so.

Thanks again for all your work and your response to my message.

• Jason

[afayes]

I agree with the comments above that this should at least be mentioned in the documentation.

[leoriviera]

@jfuss, guess who ran into this almost five years after this issue was created. This guy!

It might be useful to put a note about testing locally with SAM somewhere in the documentation.

[jasonterando]

I can see references being a problem, but conditionals really ought to be supported