Set implementation does not appropriately handle hash collisions about terraform-plugin-sdk HOT 5 OPEN

Thanks to @jvoorhis we have a simple repro of this that doesn't require creating any AWS resources:

data "archive_file" "icollide" {
  type = "zip"

  source {
    content = ""
    filename = "plumless"
  }

  source {
    content = ""
    filename = "buckeroo"
  }

  output_path = "buckeroo.zip"
}

from terraform-plugin-sdk.

Hi @mattmoyer - you're right, this is particularly nasty if you happen to encounter it. I'll give it some thought with @phinze and @mitchellh and come back to this issue once we have a plan.

from terraform-plugin-sdk.

So I think the only thing we can do here is:

• For primitive types we can do equality automatically
• For non-primitive types we'd need a equality function provided.

I don't think there is any automatic way for us to determine equality for all set elements without that. Unfortunately, most set elements are not primitives...

from terraform-plugin-sdk.

@mitchellh we already have a bunch of code that generates a proprietary string serialization of complex structures for use in the default hashing implementation. For cases where the default hash implementation is being used (I think that everything that's been added since it's existed), could we just compare the strings that produces to get deep-equality?

Presuming that there aren't any issues with that which I'm not seeing, we could plan to shift all of the older stuff (carefully) onto the default set implementation, since AFAIK there's no good reason to override the hash function and plenty of confusing behavior if you don't get it right. (such was the motivation for adding the default implementation in the first place)

from terraform-plugin-sdk.

Hi all! Sorry for the long silence here.

v0.12 includes some work towards a solution here, by switching to a new set implementation that is not subject to hash key collisions.

I've relabelled this issue as a provider-sdk one rather than a config one to reflect the fact that for the moment the provider SDK must unfortunately continue to use its own set implementation (converting from the new Terraform Core one on entry to the SDK) because the providers remain compatible with v0.11 and prior releases for the moment.

Fully addressing this problem will therefore require some revisions to the provider SDK which will come at a future point where we are comfortable ending support for Terraform v0.10 and v0.11 for new provider releases, which'll depend on how quickly the user community is able to adopt v0.12. We'll revisit this again later along with other work to introduce v0.12-specific features into the provider SDK.

from terraform-plugin-sdk.