Provider produced inconsistent final plan: "registry.terraform.io/hashicorp/aws" produced an invalid new value for │ .timeouts: was present, but now absent.

[fahadahammed]

Description

Working version of the infra code suddenly giving error from yesterday showing:

╷
│ Error: Provider produced inconsistent final plan
│ 
│ When expanding the plan for
│ module.aws_lambda.module.the_user_info_function.module.lambda_function.aws_lambda_function.this[0]
│ to include new values learned so far during apply, provider
│ "registry.terraform.io/hashicorp/aws" produced an invalid new value for
│ .timeouts: was present, but now absent.
│ 
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.

Versions

• Module version [Required]: 5.3.0

• Terraform version:1.5.3

• Provider version(s): AWS:5.8.0

Reproduction Code [Required]

module "lambda_function" {
  source = "terraform-aws-modules/lambda/aws"

  function_name   = var.function_name
  description     = var.function_description
  handler         = var.handler
  runtime         = var.runtime
  build_in_docker = true
  publish         = var.publish

  timeout = var.timeout

  source_path = var.source_path

  environment_variables = {
    MASTER_API_TOKEN = var.MASTER_API_TOKEN
  }

  allowed_triggers = {
    APIGatewayAny = {
      service    = "apigateway"
      source_arn = var.api_gateway_arn
    }
  }

  tags = var.tags
}

[antonbabenko]

Could you please provide a reproduction code with values I can run right away? Replace var.... with something valid but what is not working.

[fahadahammed]

@antonbabenko I think the variables are mostly straightforward ones.

module "the_user_info_function" {
    function_name        = "the_user_info_function"
    function_description = "This function is about giving userinfo."
    source = "./functions/the_user_info_function"
    source_path = "./lambda/functions/the_user_info_function/lambda_function.py"

    publish = true
    timeout = 10

    MASTER_API_TOKEN = var.MASTER_API_TOKEN

    api_gateway_arn = var.api_gateway_arn
    api_gateway_execution_arn = var.api_gateway_execution_arn

    rest_api_id = var.rest_api_id
    parent_id = var.parent_id

    authorizer_id = var.authorizer_id

    handler = "lambda_function.lambda_handler"
    api_path_part = "user-info"
}

[antonbabenko]

Well, in this example you are using some kind of wrapper module, and it doesn't help much to figure out the root cause of the issue. Please try to reproduce it without the wrapper, first.

[dbast]

Have the same issue.. also terraform 1.5.3 and this simplified code

module "my_function" {
  source = "terraform-aws-modules/lambda/aws"
  version = "5.3.0"

  function_name   = "my_function"
  handler         = "my_function.handler"
  build_in_docker = false
  runtime         = "python3.10"
  source_path = [
    "../my_function/"
  ]
  memory_size = 128
  timeout     = 10

  publish = true
}

The error started to appear from the upgrade of terraform-aws-modules/lambda/aws from v5.2.0 to v5.3.0.

[dbast]

Seems like the cause of this is in https://github.com/terraform-aws-modules/terraform-aws-lambda/commit/2a59ba2948fa22dd7cb7a1c8a721fa826c3832e8

timeout != timeouts.

[dbast]

So the "was present, but now absent" state issues are explained here

• Any attribute that had a known value in the planned new state must have an identical value in the new state.
• Any attribute that had an unknown value in the planned new state must take on a known value of the expected type in the new state. No unknown values are allowed in the new state.

The timeouts values when set to specific values or defaults are shown as planned state during planning (in terraform enterprise):

So the value is planned, but doesn't make it into new state during apply.

[github-actions[bot]]

This issue has been automatically marked as stale because it has been open 30 days with no activity. Remove stale label or comment or this issue will be closed in 10 days

[sneisius]

I am getting this too. What is the solution or workarounds?

[Fran-Rg]

Related somehow to https://github.com/terraform-aws-modules/terraform-aws-lambda/blob/master/main.tf#L115-L119

reverted to 5.2.0 solved it for now

[github-actions[bot]]

This issue has been automatically marked as stale because it has been open 30 days with no activity. Remove stale label or comment or this issue will be closed in 10 days

[dbast]

this is still an issue.

[dbast]

The PR that introduced "timeouts" in to the terraform-aws-lambda module is https://github.com/terraform-aws-modules/terraform-aws-lambda/pull/485

The terraform-aws-lambda module configures the resource "aws_lambda_function" of the aws provider, which supports the timeouts parameter as documented here and implemented in code function.go.

The error during terraform apply says This is a bug in the provider, which should be reported in the provider's own issue tracker. ... Does that mean the bug is in the mentioned function.go?

[FeiWangTyro]

did we fix the issue? still got the error, AWS provider version is 5.31.0

[Fran-Rg]

@dbast you're probably right, this needs to be reported on https://github.com/hashicorp/terraform-provider-aws/issues in the meantime using your PR works

[antonbabenko]

I believe, there is a better solution - https://github.com/terraform-aws-modules/terraform-aws-lambda/pull/522#pullrequestreview-1818807438

[Fran-Rg]

While this solves the initial problem caused by the timeouts values being set and improperly handled by terraform, it is possible you have already "infected" your state.

The solution I found was to check the state file and update:

            "timeouts": {
              "create": null,
              "delete": null,
              "update": null
            },

for

            "timeouts": null,

in all lambda aws_lambda_function resources

[github-actions[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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.