Brian Flad

Hi @glennsarti 👋 Sorry you ran into that frustrating situation. Since this issue was created awhile ago, provider acceptance testing functionality has been forked into the separate [terraform-plugin-testing Go module](https://pkg.go.dev/github.com/hashicorp/terraform-plugin-testing)...

Hi @timofurrer 👋 Thank you for raising this feature request. The current migration path in this case is, as you gathered, removing the `Default`/`DefaultFunc` definitions in the terraform-plugin-sdk provider schema...

Since terraform-plugin-mux v0.12.0, it no longer performs this same provider configuration data equality check across all underlying providers. It is up to provider developers to ensure their provider configuration implementations...

Related: https://github.com/hashicorp/terraform-plugin-framework/issues/709 (they will likely get fixed as best as possible at the same time)

For other maintainer's benefit, here's the relevant stack trace from framework v1.3.1: ``` 2023-06-18T17:37:34.030+0100 [DEBUG] provider.terraform-provider-bug: panic: runtime error: invalid memory address or nil pointer dereference 2023-06-18T17:37:34.030+0100 [DEBUG] provider.terraform-provider-bug: [signal...

As part of further triaging this, returning the `resp.PlannedState.GetAttribute` diagnostic yields: ``` | Error: Duplicate Set Element | | with framework_bug.test, | on terraform_plugin_test.tf line 2, in resource "framework_bug" "test":...

Hi @jacobbednarz 👋 Thank you for raising this and apologies for the delayed response. I have relabeled this issue as a feature request because this is functionality that does not...

Really appreciate that feedback, @jacobbednarz 👍 Could you maybe walk me through what you are thinking in this regard just to ensure we have a shared understanding? Maybe I am...

One of the challenges here is that human-readable outputs in Terraform are not protected by compatibility promises, so relying on the existing output might break in future versions. There are...

One additional note that I would like to cross-reference from #186 is that any potential new implementation of `GetAttribute()` and `SetAttribute()` should consider only accepting a single attribute name path...