Hi Thomas 👋
Question more than proposal — I hit something in production that the current MODULE-PATTERNS.md doesn't warn about, and I'm not 100% sure whether a caveat would fit your skill or whether it's too edge-casey. Curious what you think.
What I observed:
On Terraform v1.13.4, a resource with both a precondition block and ignore_changes inside the same lifecycle triggered a panic:
panic: duplicate status report for module.X.Y ResourcePrecondition 0
It took me ~90 minutes and three failed applies before I realised the combination itself was the trigger, not the individual blocks. The workaround that worked: drop the precondition from the resource lifecycle and move the cross-variable validation up to the caller (or into a separate null_resource / terraform_data precondition).
How sure am I that this is real and not just my setup?
Honestly: the Terraform issues I found (#31846, #35924) are closed — but they describe the same duplicate checkable objects report panic class in adjacent setups (TF 1.3 module outputs, ephemeral resources). PR #35926 only fixes the ephemeral-resources variant, so the precondition + ignore_changes permutation on regular resources still reproduces in v1.13.4. So it's a real-but-narrow gotcha, not a clear-cut Terraform bug with a single number you can point at.
My question:
Given how surgical your skill is — would a one-bullet caveat in the Lifecycle Preconditions and Postconditions Guidance: list fit? Something like:
⚠️ Combining precondition with ignore_changes on the same resource lifecycle can trigger a duplicate status report panic (observed in Terraform v1.13.4; related upstream: #31846, #35924). If a resource needs ignore_changes, move cross-variable validation to the caller.
Or do you think this is too edge-casey for the skill, and people should discover it themselves? Either answer is totally fine — I'm asking because the section currently recommends precondition unconditionally, and I lost time trusting that recommendation.
If you'd like the bullet (in whatever wording you prefer), I'm happy to open a PR. The diff would be a single line, no removals.
Thanks for the skill and the blog post — the "module design is the hard part" framing was the actual reason I started benchmarking my own setup.
— Dima
Hi Thomas 👋
Question more than proposal — I hit something in production that the current
MODULE-PATTERNS.mddoesn't warn about, and I'm not 100% sure whether a caveat would fit your skill or whether it's too edge-casey. Curious what you think.What I observed:
On Terraform v1.13.4, a resource with both a
preconditionblock andignore_changesinside the samelifecycletriggered a panic:It took me ~90 minutes and three failed applies before I realised the combination itself was the trigger, not the individual blocks. The workaround that worked: drop the
preconditionfrom the resourcelifecycleand move the cross-variable validation up to the caller (or into a separatenull_resource/terraform_dataprecondition).How sure am I that this is real and not just my setup?
Honestly: the Terraform issues I found (#31846, #35924) are closed — but they describe the same
duplicate checkable objects reportpanic class in adjacent setups (TF 1.3 module outputs, ephemeral resources). PR #35926 only fixes the ephemeral-resources variant, so theprecondition + ignore_changespermutation on regular resources still reproduces in v1.13.4. So it's a real-but-narrow gotcha, not a clear-cut Terraform bug with a single number you can point at.My question:
Given how surgical your skill is — would a one-bullet caveat in the Lifecycle Preconditions and Postconditions
Guidance:list fit? Something like:Or do you think this is too edge-casey for the skill, and people should discover it themselves? Either answer is totally fine — I'm asking because the section currently recommends
preconditionunconditionally, and I lost time trusting that recommendation.If you'd like the bullet (in whatever wording you prefer), I'm happy to open a PR. The diff would be a single line, no removals.
Thanks for the skill and the blog post — the "module design is the hard part" framing was the actual reason I started benchmarking my own setup.
— Dima