I’m trying to use the aws_wafv2_web_acl resource with its multiple rule attribute(s), which the source code says is TypeSet.
I’m using a variable to pass in a bunch of rules to create then creating them using the below to create them:
dynamic "rule" {
for_each = var.rules
...
This works, however they’re not being created in order - it seems to read the provided var in the order of first, last, second, third, … thus any time a rule is appended to the list nearly all the rules get removed and readded as the order shuffles round. However given the provider is a set, why does it care?
I’ve tried a quick [for idx in var.rules : idx.priority] in the outputs and this is returning the expected order as supplied, so I’m confused as to whether this is a problem with my logic, the resource or perhaps TF itself? It’s looking more like the resource, but the code is pretty simple, so anyone have any thoughts or ideas on how to test further?
I’m using TF 1.1.7 and the AWS provider 4.5.0, but have also tried older versions of both.
A “set” type is inherently unordered, so because the provider is using schema.TypeSet here, the order which the rules are processed is undefined. By declaring that these are a set, the provider is stating that the order does not matter, which is most likely because the remote service also cannot account for any strict ordering.
No I get that - my confusion is that it DOES seem to care about the order, as adding another item makes it redo almost the whole lot. If it’s really a set it shouldn’t matter, surely?
What you are seeing may only be an artifact of how terraform formats the change on the CLI, or it may be because the objects are all altered slightly by the provider. Because rule has a relatively complex schema and the legacy SDK type system is fairly limited, it’s probably the latter case, where some parts of the set elements are altered by the provider when there is a change to the entire set.
