New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
strange cycle errors in 1.3.0 #31843
Comments
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 Thanks! |
@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. |
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. |
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 |
Would it be possible to compare trace logs from a plan in each version? You can avoid all the provider output by using The cycle output here actually looks a bit strange, with references going back and forth from the same
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. |
After applying with 1.2.9, 1.3.1 plans successfully. So it's definitely an issue as the above with a destroy/create. I'm going to have to revert to 1.2.9 until this is resolved - I can't risk getting locked into a position where I can't make a change due to a cycling plan. The cycle I had looked like the below, and the cause for the change was a number of lambda functions having their layers changed. I know what you mean about the dependence of a provider on something (which for me is completely unavoidable), but as far as I can tell there is nothing in the list of thing being changed upon which a provider depends.
I've saved my console output around this issue for future reference, but cannot now reproduce the problem without significant impact to the project, so I'm not going to be able to provide a TRACE, although given the size of it for my module it'd be hard to make use of one. EDIT: Scratch that.. I don't know why the AWS Organization is in that cycle.. I need to find that out as that will probably be key - the organization would cause a dependent-provider issue because the AWS accounts depend on the Org and the subordinate Providers depend on the accounts. But that said, it really doesn't account for the fact that 1.2.9 had no problem planning and applying the changes. Only 1.3.1 cared. So either it's a graph construction issue in 1.3.1, or the change to 1.3.1 somehow caused a resource to change that 1.2.9 didnt need to change, that then got itself caught in a dependency deathroll. EDIT 2: I found why the org was in the list.. one of the changes was a service control policy. So, yes it's agreeable that this is somehow a combination of changes where enough resources either side of a provider were changing that the provider couldnt assert itself.. but:
|
Prior to v1.3 the apply graph could discard most of the objects entirely, which simplified things greatly and avoided problems with use cases like this. Basically the dependencies were there, but we could ignore them in almost every case. The addition of preconditions and postconditions means that we need to keep everything around longer to validate the values, which is surfacing the problem. Something I didn't think about previously though, which appears to be the case here, is that you have aws resources feeding into different aws providers' configurations! This of course seems obvious now, but the temporary workaround we have in place is only going to compare provider type (because this use case has almost always been between different providers entirely, and that's the easiest thing to check), but because they are the same type of provider we're not catching the problem at all! I think we may be able to fix the most recent patch to work here, so that a more precise solution can be worked out in a future release. |
@jbardin I do not believe this cycle bug has been resolved - we've seen cycles on a number of occasions using 1.3.2 which do not occur with 1.2.9: |
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. |
Terraform Version
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.
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
terraform apply
Additional Context
No response
References
No response
The text was updated successfully, but these errors were encountered: