@austinvalle should we add the top-level Applyable and Complete plan output flags as well?

https://github.com/hashicorp/terraform/pull/34642/files#diff-aec0f9962c6764cbde3325886b9b81650e1007d96d7693a9dcf0df9b53f09d2eR66-R67

should we add the top-level Applyable and Complete plan output flags as well?

👍🏻 to that but also it would be fine with me if this was part of a separate PR.

@austinvalle should we add the top-level Applyable and Complete plan output flags as well?

https://github.com/hashicorp/terraform/pull/34642/files#diff-aec0f9962c6764cbde3325886b9b81650e1007d96d7693a9dcf0df9b53f09d2eR66-R67

Thanks for bringing this up, @liamcervante and I had a discussion in the RFC + briefly offline about this. For some reason I took away that we didn't need the complete flag, but I think reading this back, we should actually add it to combine with checking len(DeferredChanges) == 0.

Added in 46496e3 ⚡

As for applyable, I think based on Martin's description in the PR we shouldn't need that for deferred actions, so I'll leave that out until it's actually needed.

Awesome, thanks @austinvalle!!

Indeed "applyable" is not directly related to deferred actions.

We might say that one goal of deferred actions is for more plans to be applyable, because today unknown values can make a plan non-applyable by causing errors during planning.

But the deferred actions feature doesn't need to directly interact with it. The Stacks-shaped equivalent of it does help HCP Terraform decide whether it should show the "approve" button for a particular stack plan, and the workspaces equivalent could potentially use that in future rather than having its own copy of similar logic to make that decision, but the decision for whether or not to do that is totally independent of deferred actions.

Thanks @apparentlymart!