Report but ignore lifecycle.prevent destroy set errors on destroy

[jmonfar]

When using the destroy action, if any single resource has the lifecycle.prevent_destroy flag set the whole terraform plan -destroy fails with error, preventing any use of tftarget destroy, even if you intend to use it for other resources without this flag.

In our setup, for example, we have moved our state to s3 backend, and we have prudently set the lifecycle.prevent_destroy flag for the s3 bucket where our states are stored to prevent any accidental removing. This prevents any use of tftarget there.

The proposal is to ignore the error and convert it to a warning, with the following safeguards:

• the action is destroy, no error is ignored in any other action
• even if the action is destroy, the error is ignored only if the string 'Resource .* has lifecycle.prevent_destroy set' is matched in the terraform plan -destroy output
• all the matches are listed as warnings in red before the selection list, to make the user aware of resources that will fail if selected for destruction

The proposed code is a minimal functional version. It has room for improvement, but at the cost of higher complexity:

• We assume that if terraform plan -destroy returns an error code and the match string is in place, no other possible errors are also present at the same time.
  • It is a reasonable assumption and will be the 99.999% of real cases, but there is always in theory a possibility that other errors are present on top of the lifecycle.prevent_destroy condition.
  • It is difficult to evaluate hipothetically if ignoring them could make any real harm, but my bet is that the complexity required to safely and reliably detect if there are other errors other than the lifecycle.prevent_destroy ones is not worth the cost for a very unikely corner case.
  • A possible compromise could be to leave the code by default working as before, failing with any error, and offer a optional flag to activate ignoring the lifecycle.prevent_destroy derived errors as proposed here. My bet is that users, like me, will always activate the optional flag if this kind of resources are in place to keep using tftarget. A optional flag that becomes used by default perhaps it's not worth it.
• A more useful and welcome improvement would be to exclude the resources reported with lifecycle.prevent_destroy true from the selection list. But again the complexity of the code required to do this perhaps is not worth the cost, as normally those resources will be almost always rather few and uncommon. This can be left to the user, in the worst case a non destroyable resource will be accidentally selected and the operation will fail anyway without further harm.

As a general criteria, I think that keeping the code as simple as possible will keep it more reliable and easy to maintain.

The current proposal would be the minimum required to keep tftarget usable in setups with protected resources, as the destroy function is in fact the one that justifies most using tftarget versus manual terraform destroy with --target.

If tftarget fails for destroy as a whole, it stops being useful for us and we would not use it.

[orangekame3]

Thanks, I will check this weekend.

[jmonfar]

Hello, kind reminder that the PR is still pending review and action after around 4 months... It must likely has been forgotten. -- Jordi Monfar ***@***.*** Missatge de Takafumi Miyanaga ***@***.***> del dia dv., 21 de març 2025 a les 2:01:

…

Thanks, I will check this weekend. — Reply to this email directly, view it on GitHub <#38 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACMAM5VNG3QAEXA57SKAHZ32VNQGHAVCNFSM6AAAAABZOGAJ4OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBRHE4DANZTHE> . You are receiving this because you authored the thread.Message ID: ***@***.***> [image: orangekame3]*orangekame3* left a comment (future-architect/tftarget#38) <#38 (comment)> Thanks, I will check this weekend. — Reply to this email directly, view it on GitHub <#38 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACMAM5VNG3QAEXA57SKAHZ32VNQGHAVCNFSM6AAAAABZOGAJ4OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBRHE4DANZTHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>