Concurrency Issue When Using Provider Aliases with Same Resource Type

Terraform Providers Plugin Development
1

Description

When using multiple provider aliases with the same resource type, there appears to be a concurrency issue where the wrong provider configuration is being applied to resources. This results in resources being created in the wrong region or with incorrect settings.

Steps to Reproduce

  1. Define multiple providers of the same type with different aliases in the Terraform configuration:

provider “mgc” {
alias = “northeast”
region = “br-ne1”
api_key = “api-key-1”
}

provider “mgc” {
alias = “southeast”
region = “br-se1”
api_key = “api-key-2”
}

  1. Create multiple resources of the same type, each using a different provider alias:
    resource “mgc_kubernetes_cluster” “cluster_northeast” {
    provider = mgc.northeast
    name = “cluster-northeast”
    version = “1.21”
    }

resource “mgc_kubernetes_cluster” “cluster_southeast” {
provider = mgc.southeast
name = “cluster-southeast”
version = “1.21”
}
3. Run terraform plan

Expected Behavior

Each resource should be created using the configuration of its specified provider alias. The cluster_northeast should be created in the br-ne1 region, and the cluster_southeast should be created in the br-se1 region.

Actual Behavior

All resources are being created with the configuration of a single provider, regardless of the specified alias. This results in clusters being created in the wrong region or with incorrect settings.

Additional Context

We’ve attempted to resolve this by implementing ResourceWithConfigure and using a thread-safe map to store provider data. However, the issue persists. It appears that the Configure method of the resource is always receiving the same provider data, regardless of the alias specified in the Terraform configuration.

Possible Related Code

Here’s a simplified version of our resource implementation:

type KubernetesClusterResource struct {
providerData *providerData
}

func (r *KubernetesClusterResource) Configure(ctx context.Context, req resource.ConfigureRequest, resp *resource.ConfigureResponse) {
providerKey, ok := req.ProviderData.(string)
if !ok {
resp.Diagnostics.AddError(“Unexpected Provider Configure Type”, “Expected string”)
return
}

data, exists := providerDataStore.data[providerKey]  <<<< Here it is always the same value, like a type of draw taking place between the providers.
if !exists {
    resp.Diagnostics.AddError("Provider Data Not Found", fmt.Sprintf("Unable to find provider data for key: %s", providerKey))
    return
}

r.providerData = data

}

Environment

  • Terraform version: Terraform v1.9.4
  • terraform-plugin-framework version: 1.11.0
  • Go version: >= 1.22.6
  • Operating System: Linux
1 Like
2

Hi @geffersonFerraz,

Are you certain the providers are initially being configured correctly? Terraform starts independent processes for each provider config and routes the resource calls to the corresponding process, so it would be both very surprising if this wasn’t working, and there would also not be anything you could do about it from the provider.

You also described this as a concurrency issue, are these providers operating on the same logical resources in the backend? There is nothing in the configuration which will prevent Terraform from making all the calls for each resource concurrently, even if they were through the same provider process.

3

I took a minute to try and replicate the problem, and it’s not clear how this could be happening at all. The providers processes are entirely independent, so I don’t see any concurrency issues, and a simple config with 2 resources and 2 providers always connects correctly in all our tests.

There must be something else going on in your environment to cause the providers to end up misconfigured somehow. Can you show a more complete example of what you are experiencing?

4

I work on the same team as @geffersonFerraz . The issue only occurs when we are debugging the provider. I noticed in the documentation that there are some caveats associated with debugging mode, and I would like to confirm whether this behavior is expected.

5

Oh! Yes if you use -debug to attach to the provider process then there is only a single instance of the provider. You can’t use multiple provider configurations in that case, because the same provider will be configured multiple times.

1 Like
6

Thank you for your response :grimacing:. To enhance clarity, I suggest adding this case to the debugging documentation. Additionally, it would be beneficial to display a warning about these caveats in debug mode, along with a link to the documentation, before showing the environment variables for the current session in the debug console.