Provider produced inconsistent final plan on aws_lambda_function {source_code_hash}

Terraform Providers AWS
1

Terraform v0.15.0
on linux_amd64

I am getting " Error: Provider produced inconsistent final plan "

Some brief scenario, I had successfully applied the operation using source_code_hash = "{data.archive_file.zip.output_base64sha256} " method.
Due to hashing replacement without any changes on the script ( main.py ), I decided to change my syntax to filebase64sha256(“{data.archive_file.zip.output_path}”).

With this action, I am getting an error as below {fyi: plan works but apply return error as below}:
│ When expanding the plan for
│ module.xxxxx.aws_lambda_function.lambda-function to include new values
│ learned so far during apply, provider “registry.terraform.io/hashicorp/aws”
│ produced an invalid new value for .source_code_hash: was
│ cty.StringVal(“xxxxx”), but now
│ cty.StringVal(“xxxx”).
│
│ This is a bug in the provider, which should be reported in the provider’s
│ own issue tracker.

To resolve this issue, I need to delete the existing lambda and create lambda again with the new syntax, which something that I cannot afford to produce on production environment.

Please advise/help to resolve this error. Thank you

2

Hey, I am facing the exact same issue and did anybody find a fix for this?

3

@HarshaR,

The cause of this can vary by configuration, so you should probably start a new topic with the error and relevant configuration. If it helps, the problem is not usually the resource which is showing the error, but rather something providing that resource with the incorrect data. In the example above it’s probably the source of the .source_code_hash from another resource (though that is an old version of Terraform, so there are a few other possibilities).

You can also check the logs for warnings about the value in question, where legacy providers are generating incorrect values but must be allowed for backwards compatibility.

4

Hello, I am also facing the same issue from past few days. It was working just fine before that. Any solution?

5

Hi, everyone. I ran into this issue recently, and today found a way to get around it.

Some background. Initially my lambda didn’t update. I’m new to Terraform (it’s awesome, by the way, coming from a do-it-on-the-console background). So the community informed me that I should provide the source_code_hash argument to the lambda resource. That worked, but it was wonky, as the first apply would throw the error discussed here, and the second apply would succeed. That wasn’t gonna work for me since I didn’t want to manually trigger my CI/CD pipeline a second time every time.

So out of desperation I put a timestamp in my generated zip file’s name, and voilla! Problem solved. I don’t know why, but it now works every time on the first run.

Here’s the code:

data "archive_file" "function_zip" {
  type = "zip"
  source_dir = var.function_source_location
  excludes = [ ".gitignore" ]
  output_path = "${var.function_source_location}/../function-${replace(replace(timestamp(), ":", ""), "-", "")}.zip"
}

resource "aws_lambda_function" "move_logs_lambda" {
  filename         = data.archive_file.function_zip.output_path
  source_code_hash = filebase64sha256(data.archive_file.function_zip.output_path)
  function_name    = "moveCloudFrontLogsToCloudWatch"
  role             = aws_iam_role.lambda_role.arn
  handler          = "lambda_function.lambda_handler"
  runtime          = "python3.12"

  environment {
    variables = {
      LOG_GROUP_NAME = var.log_group_name
      LOG_STREAM_NAME = var.log_stream_name
    }
  }

  tags = merge(var.global_tags, {
    Name = "${var.implementation_description}-move-cloudfront-logs-lambda"
  })

  depends_on = [
    aws_iam_role.lambda_role,
    data.archive_file.function_zip
  ]
}

I hope this saves a few hairs from being pulled out.