[Bug]: aws_lambda_invocation plan fails for deferred input values in CRUD lifecycle mode

[theipster]

Terraform Core Version

1.5.0

AWS Provider Version

5.1.0, 5.4.0 (latest at time of writing)

Affected Resource(s)

• aws_lambda_invocation

Expected Behavior

The following configuration can be successfully planned and applied:

resource "aws_lambda_invocation" "this" {
  function_name = ...
  input         = "{\"foo\":\"foo\",\"bar\":\"${time_static.arbitrary.rfc3339}\"}"

  lifecycle_scope = "CRUD"
}

resource "time_static" "arbitrary" {}

can be successfully planned and applied:

$ terraform plan ...

...

# aws_lambda_invocation.this will be created
+ resource "aws_lambda_invocation" "this" {
    + function_name   = ...
    + id              = (known after apply)
    + input           = (known after apply)
    + lifecycle_scope = "CRUD"
    + qualifier       = "$LATEST"
    + result          = (known after apply)
    + terraform_key   = "tf"
  }

# time_static.arbitrary will be created
+ resource "time_static" "arbitrary" {
    + day     = (known after apply)
    ...
    + rfc3339 = (known after apply)
    ...
    + year    = (known after apply)
  }

Actual Behavior

The Terraform configuration fails to be planned.

Relevant Error/Panic Output Snippet

$ terraform plan ...

...

# time_static.arbitrary will be created
+ resource "time_static" "arbitrary" {
    + day     = (known after apply)
    ...
    + rfc3339 = (known after apply)
    ...
    + year    = (known after apply)
  }

╷
│ Error: lifecycle_scope other than "CREATE_ONLY" requires input to be a JSON object
│
│   with aws_lambda_invocation.this,
│   on test.tf line 1, in resource "aws_lambda_invocation" "this":
│   1: resource "aws_lambda_invocation" "this" {
│

Terraform Configuration Files

# Pre-requisite resources

data "archive_file" "passthru" {
  type        = "zip"
  output_path = "${path.root}/.archive_files/passthru.zip"

  source {
    filename = "index.py"
    content  = <<-PY
      import logging

      logger = logging.getLogger()
      logger.setLevel(logging.INFO)

      def lambda_handler(event, _context):
        logger.info("Received event %s", event)
        return event
    PY
  }
}

resource "aws_lambda_function" "passthru" {
  function_name = "passthru"
  role          = <lambda-exec-role-arn>

  filename         = "${path.root}/.archive_files/passthru.zip"
  handler          = "index.lambda_handler"
  runtime          = "python3.9"
  source_code_hash = data.archive_file.passthru.output_base64sha256
}

resource "time_static" "arbitrary" {}

# The affected resource:

resource "aws_lambda_invocation" "this" {
  function_name = aws_lambda_function.passthru.function_name
  input         = "{\"foo\":\"foo\",\"bar\":\"${time_static.arbitrary.rfc3339}\"}"

  lifecycle_scope = "CRUD"
}

Steps to Reproduce

$ terraform plan

Debug Output

See above.

Panic Output

No response

Important Factoids

1. Only affects deferred input values

This bug seems to only affect configurations where the input argument is deferred (terminology?), i.e. where a plan would normally show (known after apply).

In the example above, the value of time_static.arbitrary.rfc3339 at plan-time is (known after apply).

Conversely, the following static value will plan and apply correctly:

# succeeds
resource "aws_lambda_invocation" "this" {
  function_name = ...
  input         = "{\"foo\":\"foo\",\"bar\":\"bar\"}"

  lifecycle_scope = "CRUD"
}

Even local references will plan and apply correctly:

locals {
  bar = "bar"
}

# succeeds
resource "aws_lambda_invocation" "this" {
  function_name = ...
  input         = "{\"foo\":\"foo\",\"bar\":\"${local.bar}\"}"

  lifecycle_scope = "CRUD"
}

2. String transformations do not affect the result

Using jsonencode() for the input value, compared to a raw JSON string, makes no difference.

# succeeds
input = jsonencode({
  foo = "foo",
  bar = "bar",
})

# succeeds
input = jsonencode({
  foo = "foo",
  bar = local.bar,
})

# fails
input = jsonencode({
  foo = "foo",
  bar = time_static.arbitrary.rfc3339,
})

3. Only affects CRUD lifecycle mode

Using lifecycle_scope = "CREATE_ONLY" (whether explicitly declared or by default) works correctly.

# succeeds
resource "aws_lambda_invocation" "this" {
  function_name = ...
  input         = "{\"foo\":\"foo\",\"bar\":\"${time_static.arbitrary.rfc3339}\"}"

  lifecycle_scope = "CREATE_ONLY"
}

# succeeds
resource "aws_lambda_invocation" "this" {
  function_name = ...
  input         = "{\"foo\":\"foo\",\"bar\":\"${time_static.arbitrary.rfc3339}\"}"
}

References

Possibly related to the customizeDiffValidateInput() function here: https://github.com/hashicorp/terraform-provider-aws/blob/main/internal/service/lambda/diff.go#L17-L21 (introduced via #29367).

Would you like to implement a fix?

Yes (however, seeing as the customizeDiffValidateInput() function seems like an intentional / design decision, I would appreciate some guidance first!)

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[github-actions]

This functionality has been released in v5.10.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[github-actions]

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.