Custom sort for ListNestedAttributes

[project0]

Module version

v0.6.1

Use-cases

Some backends may return items differently ordered after creation which will produce inconsistent results for the plan. I am not sure if (and how) more complex data structure is handled by the framework, but it does not seem to work in all cases.

Attempted Solutions

I have no idea how to solve this natively with the framework. Perhaps it is somehow possible with the plan modifier, but the tfsdk types are differently exposed than go structs.

However, it seems to take a lot of effort to workaround this to produce consistent results. I may can sort the results manually before returning the state, but this will only work if directly considered and may can change over time.

Proposal

Maybe the framework could respect the sort interface for slices? Not sure if this would be enough, i guess this would need to be implemented somehow at plan modifier level.

References

293

[bflad]

Hi @Project0 👋 Thank you for raising this.

As you suspect, while working with a "unordered" list, you would need to properly order the list elements to match the configuration so the value is consistently equivalent for the configuration, plan, and state. The consistency rule is enforced by Terraform core, not the framework. Fixing this in a framework provider with a list type could be done with:

• Implementing a plan modifier that disregards differently ordered list elements when comparing the plan and state, instead modifying the plan value to match the configuration value.
• Ensuring that any state setting logic, such as Read method logic, also takes similar steps to not overwrite the state with differently ordered list elements and keeping the existing value where possible.

Another option here is switching to a set, where unordered elements are inherently supported since "indexing" is based on the entire value of the element.

We are also tracking something related in #70, which likely will be an implementation where custom types could declare logic for semantically equivalent values.

Given that switching to a set implementation or waiting for #70 are likely the two best recommendations right now, I think I'm going to opt to close this out for now with the issue linking serving as a friendly reminder about this specific use case for that type of functionality. Thanks again.

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.