Terraform-provider-aws: Empty map assignment fails

[hashibot]

_This issue was originally opened by @betabandido as hashicorp/terraform#15651. It was migrated here as a result of the provider split. The original body of the issue is below._

---

I have developed a module that creates AWS lambda functions. When I tried to let users pass environment variables to the module (so that they can be passed to aws_lambda_function) I got into an issue where assigning a map to a variable fails if the map is empty.

Terraform Version

Terraform v0.10.0-rc1-dev

Terraform Configuration Files

Partial contents of the module file:

variable "variables" {
  type = "map"
  default = {}
}

resource "aws_lambda_function" "lambda_function" {
  # ...

  environment {
    variables = "${var.variables}"
  }
}

When the code using the lambda module does not define any variables, var.variables defaults to an empty map. When terraform tries to assign the map to environment.variables I get the following error:

Error applying plan:
1 error(s) occurred:
* module.lambda.aws_lambda_function.lambda_function: 1 error(s) occurred:
* aws_lambda_function.lambda_function: At least one field is expected inside environment

If I pass some environment variables to the module, or if I define var.variables as:

variable "variables" {
  type = "map"
  default = { dummy_ = "1" }
}

then, I do not get any error and terraform successfully creates the lambda function.

This issue does not seem to be strictly related to the AWS provider, but it seems to affect the terraform core. Could you please have a look into it? The problem itself occurs in the following line of code: https://github.com/terraform-providers/terraform-provider-aws/blob/master/aws/resource_aws_lambda_function.go#L313

You can find the complete code for the module here: https://github.com/betabandido/TerraformModules/blob/feature/lambda-env-vars/modules/lambda/main.tf

[scott-r-lindsey]

Well, I spent about four hours trying to modularize my Lambda functions before I ended up here. Here's the thing: Lambda@Edge requires that environment variables ARE NOT SET. If they are set, your cloudfront errors out with:

InvalidLambdaFunctionAssociation: The function cannot have environment variables

The only solution is to copy and paste the my entire "_lambda_function_" module as "_lambda_no_vars_function_", just to unset the environment variables.

I want to advocate for Terraform, but that's hard to do when I so often found my self travelling down the rabbit hole to deal with one "quirk" or another.

[scott-r-lindsey]

Oh, and BTW this workaround will negatively your lambda cold start times because those environment variables need to be pulled from KMS.

[nmartinnez]

I had the same problem and I solved it by passing a conditional:
 count = "$ {var.has_environment ? 1: 0}"
and I add the variable:

variable "has_environment" {    type = "string"    description = "true or false"    default = "true" }

[kongakong]

@nmartinnez How did you use count and has_environment to solve it? Is it not entirely clear to me.

[nmartinnez]

Hello @kongakong, what I did was in the module that I am using, I wrote two blocks in the main one, one with environment and another if environment, then I put a count of the two blocks:
count = "$ {var.has_environment? 1: 0}"
and then I wrote a variable

variable "has_environment" {    type = "string"    description = "true or false"   default = "false" }
and in the module I pass the has_environment variable only if I need to add that field if I don't pass a false so that I don't create the block that has those variables

if it works for you here I pass the module I am using:
https://registry.terraform.io/modules/corpit-consulting-public/lambda-function-mod/aws/0.2.0

[bflad]

Hi folks 👋

This issue is resolved in Terraform 0.12, released a year ago, which supports new functionality in the configuration language aimed at solving problems like these. The new dynamic block syntax can be used to dynamically generate configuration blocks and their arguments. Given that there is a general configuration language fix for these situations, I'm going to close this issue.

If you're looking for general assistance with how to implement dynamic in this situation, please note that we use GitHub issues in this repository for tracking bugs and enhancements with the Terraform AWS Provider codebase rather than for questions. While we may be able to help with certain simple problems here it's generally better to use the community forums where there are far more people ready to help, whereas the GitHub issues here are generally monitored only by a few maintainers and dedicated community members interested in code development of the Terraform AWS Provider itself.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!