Stephen Lewis (Burrows)

basically if we could avoid solving the nested write-only arguments problem for now that would be great.

That seems like a reasonable split. I'd be fine with reviewing the constraint group logic without a specific relevant write-only field being added, since it seems to work as expected...

The templating changes for nested changes (go + markdown) might make sense to do in the same PR, but with some other nested sensitive field that's not as complicated as...

Thanks, I know it's more effort to split it into PRs but it will make it easier/safer to review. I want to be extra cautious since we've had some issues...

mm.... I guess let's just keep it all in this PR and add the nested write-only markdown generation handling changes here. It's going to be a bit of a pain...

It's possible I'm missing something, but it looks like previously, we weren't storing sensitiveLabels in state, and after this change, we will be. Is that correct to your understanding? If...

This is enabled in the API via region-specific endpoints: https://docs.cloud.google.com/apigee/docs/api-platform/get-started/drz-concepts#data-residency-service-endpoint In MMv1 that will need to be implemented as a separate product due to https://github.com/hashicorp/terraform-provider-google/issues/12738

It looks like this may not be available in the API, so I'm marking it as an upstream issue. Please let us know if that's incorrect!

Is this ticket resolved at this point?

I think the resource is now supported with https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/firebase_apple_app, but I don't see a field that seems to correspond with apns_auth_key.