strange cycle errors in 1.3.0

[jbg]

Terraform Version

Terraform v1.3.0
on darwin_arm64
+ provider registry.terraform.io/hashicorp/aws v4.31.0
+ provider registry.terraform.io/hashicorp/kubernetes v2.13.1

Terraform Configuration Files

Unable to provide.

Debug Output

Unable to provide.

Expected Behavior

In Terraform 1.2.9, the configuration applies without any issue.

Actual Behavior

In Terraform 1.3.0, a cycle is detected, even though several of the resources listed adjacently in the cycle do not have any (implicit or explicit) dependency on each other.

│ Error: Cycle: aws_subnet.sin["ap-southeast-1a"], aws_iam_role.sin_cluster, aws_subnet.sin["ap-southeast-1c"], aws_vpc.sin, aws_subnet.sin["ap-southeast-1b"], provider["registry.terraform.io/hashicorp/kubernetes"], kubernetes_manifest.eventlistener (destroy), aws_kms_key.sin_cluster, aws_eks_cluster.sin

Perhaps notably, the kubernetes_manifest.eventlistener resource is tainted and will be replaced.

Downgrading to 1.2.9, the exact same configuration applies without any issue.

Steps to Reproduce

1. terraform apply

Additional Context

No response

References

No response

[jbardin]

Hi @jbg,

Thanks for filing the issue. Without any configuration or logging there's not much to go by here. Would it be possible to create a more minimal reproduction, or a redacted trace log? Using TF_LOG_CORE=trace will significantly reduce the log output, and contains graph information which might lead to the root cause.

Thanks!

[jbg]

@jbardin I've just tested with v1.3.1 and the problem still exists. I haven't had time to try to make a minimal reproduction yet. The issue seems to happen when resources are going to be destroyed and recreated, and the outputted cycle error always lists those resources as well as their providers in the cycle. The problem exists on both v1.3.0 and v1.3.1, but not on v1.2.9. I will try to get time to make a reproduction or redacted trace log this week.

[jbardin]

Thanks @jbg, this cycle looked very much like what the linked PR handles, so I linked them. They may still be related, but I'll reopen this for further investigation.

[Zordrak]

I dont know how easy it's going to be to provide evidence as the module I'm using is absolutely huge.. but I just wanted to confirm that this is definitely a problem in 1.3.1, fine in 1.2.9

[jbardin]

Would it be possible to compare trace logs from a plan in each version? You can avoid all the provider output by using TF_LOG_CORE=trace, though it's still going to be quite a lot if the config is that large.

The cycle output here actually looks a bit strange, with references going back and forth from the same aws_subnet.sin resource, which would imply that the aws_subnet.sin resource somehow references itself which should always have been a cycle:

aws_subnet.sin["ap-southeast-1a"],
aws_iam_role.sin_cluster,
aws_subnet.sin["ap-southeast-1c"],
aws_vpc.sin,
aws_subnet.sin["ap-southeast-1b"]

I'm wondering if this cycle is just a manifestation of one of the unsolvable ordering situations you can get when a provider depends on a managed resource, which is why it's recommended to not ever have that situation in the first place. The usual issue is just that the provider fails because it cannot get the necessary config data at the right time, but maybe we'll find that the ordering prior to v1.3 was underspecified in some cases.