Fix compute_service_attachment consumer_accept diff

[horjulf]

Fixes hashicorp/terraform-provider-google#12409

If this PR is for Terraform, I acknowledge that I have:

• Searched through the issue tracker for an open issue that this either resolves or contributes to, commented on it to claim it, and written "fixes {url}" or "part of {url}" in this PR description. If there were no relevant open issues, I opened one and commented that I would like to work on it (not necessary for very small changes).
• Generated Terraform, and ran make test and make lint to ensure it passes unit and linter tests.
• Ensured that all new fields I added that can be set by a user appear in at least one example (for generated resources) or third_party test (for handwritten resources or update tests).
• Ran relevant acceptance tests (If the acceptance tests do not yet pass or you are unable to run them, please let your reviewer know).
• Read the Release Notes Guide before writing my release note below.

Release Note Template for Downstream PRs (will be copied)

compute: Fixed permadiff for `consumer_accept_lists` in `google_compute_service_attachment`

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[modular-magician]

Hello! I am a robot who works on Magic Modules PRs.

I've detected that you're a community contributor. @slevenick, a repository maintainer, has been assigned to assist you and help review your changes.

❓ First time contributing? Click here for more details

---

Your assigned reviewer will help review your code by:

• Ensuring it's backwards compatible, covers common error cases, etc.
• Summarizing the change into a user-facing changelog note.
• Passes tests, either our "VCR" suite, a set of presubmit tests, or with manual test runs.

You can help make sure that review is quick by running local tests and ensuring they're passing in between each push you make to your PR's branch. Also, try to leave a comment with each push you make, as pushes generally don't generate emails.

If your reviewer doesn't get back to you within a week after your most recent change, please feel free to leave a comment on the issue asking them to take a look! In the absence of a dedicated review dashboard most maintainers manage their pending reviews through email, and those will sometimes get lost in their inbox.

---

[modular-magician]

Hi! I'm the modular magician. Your PR generated some diffs in downstreams - here they are.

Diff report:

Terraform GA: Diff ( 1 file changed, 24 insertions(+), 18 deletions(-))
Terraform Beta: Diff ( 1 file changed, 24 insertions(+), 18 deletions(-))
TF Validator: Diff ( 3 files changed, 6 insertions(+), 3 deletions(-))

[modular-magician]

Tests analytics

Total tests: 2191
Passed tests 1948
Skipped tests: 239
Failed tests: 4

Action taken

Triggering VCR tests in RECORDING mode for the tests that failed during VCR. Click here to see the failed tests

TestAccFirebaserulesRelease_BasicRelease|TestAccComputeServiceAttachment_serviceAttachmentBasicExample|TestAccComputeServiceAttachment_serviceAttachmentBasicExampleUpdate|TestAccComputeRegionNetworkEndpointGroup_regionNetworkEndpointGroupPscServiceAttachmentExample

[modular-magician]

Tests passed during RECORDING mode:
TestAccFirebaserulesRelease_BasicRelease[Debug log]
TestAccComputeServiceAttachment_serviceAttachmentBasicExample[Debug log]
TestAccComputeServiceAttachment_serviceAttachmentBasicExampleUpdate[Debug log]
TestAccComputeRegionNetworkEndpointGroup_regionNetworkEndpointGroupPscServiceAttachmentExample[Debug log]

All tests passed
View the build log or the debug log for each test

[slevenick]

Unfortunately changing from a list to a set is considered a breaking change because it changes how users can access these values in another resource.

We can add this during our next major version release though

[horjulf]

@slevenick its kinda broken as is, it diffs on every run, only solution currently is to ignore the field which isn't great. 😞

Is a new major release in the plans for the near future ?

[slevenick]

Next major release is 5.0.0 but it hasn't been scheduled as far as I know.

A potential workaround could be something like resourceBigtableInstanceClusterReorderTypeList in the bigtable_instance resource, which handles the list -> set conversion within a CustomizeDiff rather than actually changing the schema types. We'll probably want to evaluate this before implementation, as implementation could be tricky.

@ScottSuarez you were tagged on the underlying bug to do additional investigation, did that happen?

[ScottSuarez]

It's as you say. List to Set is going to be a breaking change. If we could do a customizediff that would resolve the issue.

We could also ignore read of the resource. Which would cause other problems, but allow the stability on the configuration state.

[ScottSuarez]

Adding comment from other thread here.
There are a couple options to resolve this.

• List -> Set: This is a breaking change, would need to wait for a major release
• Ignore read of the field. This would make it so terraform state is the only reality terraform is aware of. Updating out of band won't make any difference. Not ideal but this scenario is already broken as is.
• CustomizeDiff to ignore a difference and treat the list as a Set. Similar to resourceBigtableInstanceClusterReorderTypeList
• Custom flatten for this array where the setting of the field in state does not set anything if it already equivalent by writing a custom compare method.

[c2thorn]

moved this to #9058