Backport of Validate duplicate provider local names in required_providers
into v1.2
#31251
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport
This PR is auto-generated from #31218 to be assessed for backporting due to the inclusion of the label 1.2-backport.
The below text is copied from the body of the original PR.
Adding multiple local names for the same provider type in
required_providers
was not prevented, which can lead to ambiguous behavior in Terraform. Providers are always located via the provider's fully qualified name (even using the full name as a map key in many places), so duplicate local names cannot be differentiated. This can lead terraform to non-deterministically configure the incorrect provider in some cases.Because it is currently possible that a configuration with providers which themselves do not need explicit configuration may have been working with duplicates, we cannot turn these into errors. Adding multiple entries for the same provider now results in a warning like so:
We can also check for the situation where a user required a provider by a name different from the default, but attempted to configure that provider via the default local name. This can help prevent the case where a provider configuration may apparently not always be taking effect within a module. The warning here is worded slightly differently:
fixes #31196