Terraform framework Optional inside a SetNestedAttribute produces a `does not correlate with any element in actual`

Terraform Providers Plugin Development
2

Hi @bvargasre,

Terraform itself requires that a provider must produce a new state that matches what was proposed during the plan phase, or return an error explaining why that isn’t possible.

A set of objects that contains a mixture of user-provided and API-provided attributes, as you seem to have here, makes that contract hard to uphold because set elements are identified only by their content and so Terraform must try to find an element from the plan that seems to match each element of the final result, or vice-versa.

Aside from that, API-decided attributes (“computed” attributes, in Terraform’s terminology) inside a set of objects are also pretty inconvenient for use elsewhere in the configuration given that there’s no separate index or key to look them up by, and so module authors must resort to complicated for expressions to project the set into a more useful data structure, such as a map.

With that in mind, I have two recommendations:

  1. Make all of the attributes in this set be either required or optional, and not “computed”. Writing a set of objects is convenient for declaring the argument values, but it’s not convenient for referring to generated values from expressions elsewhere.
  2. If you have any attributes you need to return from the API, rather than being specified by the module author, declare a separate attribute that’s entirely “computed” and whose type is something that’s more ergonomic to use in expression references, such as a map of objects where the keys are something an author can predict and access directly without having to reshape the structure themselves first.

This will firstly make the provider API more ergonomic to use, but it will also secondarily help with your problem, because the set of objects will then always exactly match what the author wrote in their configuration, and the separate result attribute will be exclusively generated by the provider and never have to agree with something the module author specified, and therefore you won’t have any situations where Terraform needs to try to match a configuration object with a computed object to prove that the provider is behaving correctly.

1 Like