v5.3.1 does not fix "ami variable when using without ssm" for fresh apply

[ghost]

Description

• ✋ I have searched the open/closed issues and my issue is not listed.

Release v5.3.0 introduced a change to "Remove call data ssm parameter when ami id is specified." This change was then modified in v5.3.1 to make this logic more robust through a nested try(coalesce(...)) statement.

Unfortunately, the current implementation fails on a cold apply (i.e., no existing infrastructure), with terraform plan returning the following error:

Error: Invalid count argument

  on .terraform/modules/ec2_server.ec2/main.tf line 10, in data "aws_ssm_parameter" "this":
  10:   count = local.create && var.ami == null ? 1 : 0

The "count" value depends on resource attributes that cannot be determined
until apply, so Terraform cannot predict how many instances will be created.
To work around this, use the -target argument to first apply only the
resources that the count depends on.

Versions

• Module version [Required]: any version from v5.3.0 onward (up to v5.6.1)

• Terraform version: v1.5.7

• Provider version(s):

• provider registry.terraform.io/hashicorp/aws v5.40.0
• provider registry.terraform.io/hashicorp/external v2.3.3
• provider registry.terraform.io/hashicorp/local v2.5.1
• provider registry.terraform.io/hashicorp/random v3.6.0
• provider registry.terraform.io/hashicorp/time v0.11.1
• provider registry.terraform.io/hashicorp/tls v4.0.5

Reproduction Code [Required]

Steps to reproduce the behavior:

1. create a new project
2. create a new EC2 instance with the "terraform-aws-modules/ec2-instance/aws" module
3. include an AMI ID in the ami input variable
4. run terraform init
5. run terraform plan <-- produces error (see above)

Expected behavior

Prior to v5.3.0, the module works as-expected.

Actual behavior

Starting with v5.3.0, the module produces an error (see above).

[imunhatep]

Same here.
This module used as (terraform code) -> module1 -> module2 -> aws-ec2 module.

In case AMI id is determined dynamically in module2 with data aws_ami , there is no way terraform plan won't fail. And the only workaround seems to define ami id as a string, directly, yet enforcing this approach is an unusable nonsence.

[github-actions]

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

[imunhatep]

/remove-lifecycle stale

[github-actions]

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

[github-actions]

This issue was automatically closed because of stale in 10 days

[imunhatep]

how convenient.. no need to resolve, respond or discuss issues. Simply wait a bit and vuala - no issues 🥇

[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.