Request for more info: InvalidComputedNestedAttributeWithWriteOnly

[marshallford]

Hello 👋🏼

I'm bumping into the following error when trying to implement a WriteOnly attribute within a computed nested attribute.

"some_attribute" is a Computed nested attribute that contains a WriteOnly child attribute.

It's pretty clear that this is a well understood limitation of the framework or terraform itself, but I would appreciate any other context that can be shared. In particular, Is it possible that this limitation will be lifted in future updates?

Thanks.

[austinvalle]

Hey there @marshallford 👋🏻,

Attributes that are write-only are designed to be configuration-only, so they can accept a value from configuration as long as they plan/apply null so Terraform doesn't store the value in any artifacts (it doesn't even have the option to do it by accident 😆). It's a one-way data flow; data comes into the provider, doesn't come out. With that design, write-only attributes cannot produce ephemeral data back to Terraform, so they can't be used directly with computed.

Having write-only attributes as children of nested attributes that are computed would be a little awkward for planning, since the parent would be defined as being able to choose it's value (computed), while one of the children values must be null regardless of the parent. There are some specific consequences that come to my mind, such as not being able to mark the parent attribute as unknown, since Terraform must ensure that the provider never produces a value for a write-only attribute, both during plan and apply.

It might be possible for a computed nested attribute to have a write-only attribute if we removed some of the default planning logic from computed attributes, but we opt-ed to not combine them at all since we already have a good deal of confusing behavior with just Optional + Computed, and this would be adding yet another confusing combination 😆.

---

Given all this, I'd say that it's unlikely we would remove this restriction specifically from Framework. It's probably more likely that we would prefer to introduce some form of "producing" ephemeral attribute for managed resource, although that is a pretty significant ask that we aren't currently working on ATM. (I'm not even sure that's been suggested on the core side, but it would need to be started over there)

Hopefully that helps add some context! I'll leave the issue open if you have any more thoughts.

[marshallford]

Thanks for all of the info. Sounds like I'll have to rethink the resource schema in question to implement the write-only attribute. I'm currently using SingleNestedAttribute as a way to organize related attributes (this resource does not have an API object that I need to model 1:1) and the write-only attribute fit nicely into a category. I'll have eliminate this SingleNestedAttribute and "hoist" all of the attributes to the root in order to avoid confusing end users with a split approach.

[chrismarget-j]

FWIW, I think @marshallford's approach looks pretty reasonable.

I would have expected this to work. I'm glad I'm not faced with creating a confusing schema to satisfy this constraint.

[austinvalle]

Yeah 🙁 , write-only attributes are kind of a "special hole" we poked in managed resources to allow them to interact with ephemeral data. The initial goal with the project was to carve a reasonably narrow path for them to work without creating too many bugs 😆.

Since this issue was opened as a request for more info I'm going to close it. If anyone in the future wants to create a formal feature request with perhaps some use-cases, we could gauge interest there.