[ISSUE] Could not load the schema for databricks provider version 1.60.0 (or newer)

[ketabruce]

Terraform & provider versions

Terraform v1.14.8 on windows_amd64 (Windows 11 OS Build 26200.8246)
Databricks provider v1.60.0

Configuration

terraform {
  required_providers {
    azurerm    = "= 4.69"
    databricks = {
      source  = "databricks/databricks"
      version = "= 1.60.0"
    }
  }
}

provider "azurerm" {
  features {}
}

Expected Behavior

terraform plan creates plan

Actual Behavior

Error while loading schemas for plugin components: Failed to obtain provider schema: Could not load the schema for provider registry.terraform.io/databricks/databricks: failed to retrieve schema from provider

Steps to Reproduce

1. terraform init
2. terraform plan

Is it a regression?

Last Databricks provider version to work on my system is 1.59.0.

Debug Output

2026-04-19T19:24:42.915+0200 [DEBUG] provider.terraform-provider-databricks_v1.60.0.exe: Databricks Terraform Provider
2026-04-19T19:24:42.915+0200 [DEBUG] provider.terraform-provider-databricks_v1.60.0.exe:
2026-04-19T19:24:42.915+0200 [DEBUG] provider.terraform-provider-databricks_v1.60.0.exe: Version 1.60.0
2026-04-19T19:24:42.915+0200 [DEBUG] provider.terraform-provider-databricks_v1.60.0.exe:
2026-04-19T19:24:42.915+0200 [DEBUG] provider.terraform-provider-databricks_v1.60.0.exe: https://registry.terraform.io/providers/databricks/databricks/latest/docs
2026-04-19T19:24:42.915+0200 [DEBUG] provider.terraform-provider-databricks_v1.60.0.exe:
2026-04-19T19:24:42.921+0200 [INFO] provider.terraform-provider-databricks_v1.60.0.exe: configuring server automatic mTLS: timestamp="2026-04-19T19:24:42.921+0200"
2026-04-19T19:24:42.929+0200 [DEBUG] provider.terraform-provider-databricks_v1.60.0.exe: plugin address: address=127.0.0.1:10000 network=tcp timestamp="2026-04-19T19:24:42.929+0200"
2026-04-19T19:24:42.929+0200 [DEBUG] provider: using plugin: version=6
2026-04-19T19:24:43.943+0200 [WARN] provider.stdio: stdio service not available, stdout/stderr syncing unavailable
2026-04-19T19:24:43.943+0200 [WARN] provider.stdio: stdio service unavailable, run will do nothing
2026-04-19T19:24:43.943+0200 [ERROR] plugin6.(*GRPCProvider).GetProviderSchema: error="rpc error: code = Unavailable desc = connection error: desc = "transport: error while dialing: dial tcp 127.0.0.1:10000: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.""
2026-04-19T19:24:45.944+0200 [WARN] provider: plugin failed to exit gracefully
2026-04-19T19:24:45.947+0200 [ERROR] provider: plugin process exited: plugin=.terraform/providers/registry.terraform.io/databricks/databricks/1.60.0/windows_amd64/terraform-provider-databricks_v1.60.0.exe id=14132 error="exit status 1"

[alexott]

1.60 is very old - use a newer version

[ketabruce]

1.60 is very old - use a newer version

Probably it was confusing, but 1.59.0 is the LAST working version, NO newer ones (1.113.0) are working.
First non working version is 1.60.0.

[alexott]

Root Cause Analysis

This is almost certainly a Windows-specific environment issue, not a provider bug. Here's why:

1. No networking/startup code changes between v1.59.0 and v1.60.0: Both versions use identical plugin infrastructure:
   - hashicorp/go-plugin v1.6.2
   - google.golang.org/grpc v1.67.1
   - hashicorp/terraform-plugin-go v0.25.0
   - Same Go version (1.22)
   - No changes to main.go, providers.go, or any startup path
2. The only meaningful code changes were:
   - SDK bump (v0.52.0 → v0.53.0) generating updated TF structs
   - New databricks_credential resource added
   - Minor internal refactors (ConvertToAttribute, etc.)
3. The error pattern is a classic Windows localhost gRPC issue: The provider successfully binds to the port, but the connecting party
   (Terraform) gets connectex: A connection attempt failed because the connected party did not properly respond.

This points to one of:

• Windows Defender Firewall: Each new provider binary is a new executable. v1.59.0 may have been allowed through the firewall previously, while all newer binaries are treated as new, unsigned applications and silently blocked.
• Hyper-V dynamic port reservations: Windows 11 has Hyper-V enabled by default. It reserves TCP port ranges via netsh. If port 10000 falls within a reserved range, the OS can silently black-hole incoming TCP SYN packets even though bind() succeeds.
• Antivirus/EDR software: May intercept inter-process localhost communication for new binaries.

Suggested Response to User

I'd recommend asking for diagnostic information:

Could you try the following troubleshooting steps on your Windows 11 machine?

1. Check Hyper-V port exclusions:

     netsh interface ipv4 show excludedportrange protocol=tcp

If port 10000 is in a reserved range, that's the cause.

2. Check Windows Firewall:

   • Open "Windows Defender Firewall with Advanced Security"
   • Look under Inbound Rules for any entries allowing/blocking the terraform-provider-databricks binary
   • Try temporarily disabling Windows Firewall and re-running terraform plan

3. Try setting the TF_LOG=TRACE environment variable and run:

     terraform providers schema -json > nul

 This isolates schema loading from other plan operations.

4. Verify with a different provider (e.g., does a standalone azurerm provider schema load work?).

5. If using antivirus/EDR software, check if it has any notifications about blocked connections.

This is not a provider-side bug that can be fixed in the codebase — the gRPC/plugin stack is unchanged between the working and broken versions.

[ketabruce]

Thanks @alexott for your answer and explanation!

Yes, it's probably not a bug with the provider but the Windows environment, since I have a similar Windows virtual machine where 1.113.0 works fine. Anyway it's still an issue for me because I'd like to use the most recent version of the provider on the host machine as well.

Let me answer your suggestions to dig deeper in possible causes for the issue:

1. Hyper-V port exclusions:
   There are no port exclusions listed by the suggested command

2. -5. Windows Firewall and antivirus/EDR
   I'm not using built-in Windows firewall software but I have ESET Internet Security installed and running.
   I have already tried to disable both firewall and file system protection settings, and also I have not found any alerts that would sign that any new binary or port opening would be blocked. ***

3. Clean provider list with TF_LOG=TRACE doing only schema loading
   Same debug output is printed as it's in the issue description

terraform {
  required_providers {
    databricks = {
      source  = "databricks/databricks"
      version = "= 1.60.0"
    }
  }
}

4. Using different provider only
   Schema loading without Databricks provider works

I also believe it's an issue on my Windows environment side, so I would be grateful if you could point me in the right direction with other suggestions to investigate further for the cause of the issue. Thank you in advance!

*** UPDATE:
1.113.0 - Fails to load schema
1.112.0 - Fails to load schema
1.111.0 - Fails to load schema
1.110.0 - Fails to load schema
1.109.0 - Fails to load schema
1.108.0 - Fails to load schema
1.107.0 - LOADS
1.106.0 - Fails to load schema
1.105.0 - Fails to load schema
1.104.0 - Fails to load schema
1.103.0 - Fails to load schema
1.102.0 - LOADS

(These were results with ESET antivirus software enabled or disabled, so the results seem to be irrespective of the antivirus software being used or not)

I'm not sure whether I should close the issue since it might be only a local environment setup problem, please let me know if I should do so. Thank you!

[alexott]

Unfortunately, I don't have Windows for testing...