Provider-level string type arguments should all have non-empty-string validation in the plugin-framework provider schema

[SarahFrench]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
• Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.
• If an issue is assigned to a user, that user is claiming responsibility for the issue.
• Customers working with a Google Technical Account Manager or Customer Engineer can ask them to reach out internally to expedite investigation and resolution of this issue.

Description

Currently the Google provider offers validation feedback to users when they set some provider-level string fields as empty strings. In the past empty strings would be silently ignored, because the SDK treats empty strings and null or unknown string values in the same way. In the plugin-framework empty strings are acknowledged and used because the PF can differentiate "" from null/unknown strings. This can lead to bugs such as this one, specifically about credentials: https://github.com/hashicorp/terraform-provider-google/issues/14255.

We should have consistent validation on string provider-level arguments but we currently do not.

Fields where validation rejects an empty string value:

• credentials
• access_token
• impersonate_service_account
• project
• billing_project
• region
• zone

Fields currently missing validation for empty strings:

• request_timeout
• request_reason
• universe_domain
• terraform_attribution_label_addition_strategy

It's worth noting that adding new validation in the schema of the plugin-framework provider is a breaking change:

• Even if a user is not using plugin-framework implemented resources in their configuration the PF provider will validate the inputs passed to it when it's configured at the start of any terraform command.
• This means if their configuration previously had request_reason="" that config ran without error, but after upgrading the provider there would be an error returned before planning/applying can start.

New or Affected Resource(s)

• google_XXXXX

Potential Terraform Configuration

N/A

References

No response

[SarahFrench]

Note to add: This suggested change is still relevant after the 'muxing fix' changes I am in the process of getting accepted and merged because even when the SDK and PF providers share the same meta the SDK and PF providers will have separate schemas. Validation placed on the PF schema that can detect and reject empty strings benefits the 'whole' provider, regardless of whether a user's config is provisioning anything implemented with the PF.

[SarahFrench]

Labelled as plugin-framework because this would be achieved by adding a Validator on the PF provider's schema, similar to this:

https://github.com/hashicorp/terraform-provider-google/blob/e92b53f3b83c4b154e8923ec92dcd15f8b71236d/google/fwprovider/framework_provider.go#L90-L95