Handling attribute required during Create but not returned during Read

I’ve been doing some research on this and it seems like I’m going to want write-only attributes. I’m new to the semantics of write-only attributes and haven’t used them before. I’ll double check tomorrow if the version of the framework I’m using supports write-only attributes.

Regardless, I have an attribute on a resource that’s required by the upstream API during Create but not returned by the upstream API during Read. This presents issues during import where importing the resource with the attribute set in the configuration results in Terraform wanting to replace the resource immediately after import.

Is this the right use case for write-only attributes? Is there anything else I can or should do outside of write-only attributes?

If you’re curious about my concrete problem I’ve created GitHub · Where software is built with more details about my specific use case.

Yes, you can use a write-only attribute to solve this sort of issue, which is probably the easiest solution because Terraform never expects the provider to return a value there.

The way it would have been done prior to write-only attrs is to modify the plan to return the prior state for that attribute (which can just be null) if the resource already exists. The rules for planning allow the provider to choose the prior state over the config if there is no semantic difference between the two.

Thank you! The write-only attribute is working as I expected it to. Now we just have to determine whether we want to use it and take the forced upgrade to Terraform for this resource.