Multiple "Provider produced inconsistent result after apply" errors with fivetran_destination

[jhiza]

Describe the bug

The fivetran_destination resource produces "Provider produced inconsistent result after apply" errors in two related scenarios:

1. PrivateLink with Databricks: When using networking_method = "PrivateLink" with Databricks destinations, Fivetran's API returns modified values for config.server_host_name (changed to PrivateLink endpoint) and config.cloud_provider (changed from "AZURE" to "AWS").

2. Toggling run_setup_tests: When changing run_setup_tests from false to true, the private_link_id field becomes null because the setup test API response doesn't include networking-related fields.

To Reproduce

Create a Terraform configuration with a Databricks destination using PrivateLink:

resource "fivetran_group" "example_group" {
  name = "example_group"
}

resource "fivetran_destination" "databricks_pl" {
  group_id             = fivetran_group.example_group.id
  service              = "databricks"
  time_zone_offset     = "0"
  region               = "AZURE_EASTUS"
  trust_certificates   = true
  trust_fingerprints   = true
  daylight_saving_time_enabled = true
  run_setup_tests      = false
  networking_method    = "PrivateLink"
  private_link_id      = "your_private_link_id"

  config {
    auth_type             = "PERSONAL_ACCESS_TOKEN"
    catalog               = "your_catalog"
    server_host_name      = "adb-xxxxxxxxxxxxxxx.xx.azuredatabricks.net"
    port                  = 443
    http_path             = "/sql/1.0/warehouses/your_warehouse"
    cloud_provider        = "AZURE"
    personal_access_token = "your_token"
  }
}

Then run:

terraform apply

Expected behavior

Terraform should successfully create or update the destination resource without state inconsistencies. The server_host_name and cloud_provider values in the Terraform state should match the values specified in the configuration.

Logs & Output

Scenario 1: PrivateLink with Databricks

│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to fivetran_destination.databricks_pl, provider produced an unexpected new value: 
│ .config.server_host_name: was cty.StringVal("adb-xxxxxxxxxxx.xx.azuredatabricks.net"), 
│ but now cty.StringVal("xxxxxxxxxx.eastus.azure.fivetran.com").

│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to fivetran_destination.databricks_pl, provider produced an unexpected new value: 
│ .config.cloud_provider: was cty.StringVal("AZURE"), but now cty.StringVal("AWS").

Scenario 2: Toggling run_setup_tests

│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to fivetran_destination.databricks_pl, provider produced an unexpected new value: 
│ .private_link_id: was cty.StringVal("xxxxxxxxxxxxxxx"), but now null.

Plugin version:

Affects versions 1.9.14 and earlier.

Additional context

Root Causes:

1. PrivateLink Config Modification: When PrivateLink is configured for Databricks destinations, Fivetran's API returns modified values for server_host_name (replacing the Azure Databricks hostname with the PrivateLink endpoint) and cloud_provider (incorrectly changing "AZURE" to "AWS"). The provider was blindly accepting these modified values from the API response.

2. Setup Test Legacy Response: When changing run_setup_tests from false to true without other config changes, the provider uses a legacy API endpoint that doesn't return networking-related fields (private_link_id, networking_method, hybrid_deployment_agent_id), causing them to become null in state.

Current Workaround:
Users must create the destination with Direct mode and run_setup_tests = false

Users must add a lifecycle block to ignore these fields:

lifecycle {
  ignore_changes = [
    config.server_host_name,
    config.cloud_provider,
    private_link_id,
    networking_method,
  ]
}

Then, users must create the destination with PrivateLink mode and run_setup_tests = false

This workaround prevents detection of actual configuration drift and is not ideal.

Impact:

• Affects any user deploying Databricks destinations with PrivateLink
• Affects any user toggling run_setup_tests on destinations with networking configuration
• Blocks automation and CI/CD pipelines
• Forces users to use workarounds that hide legitimate configuration changes

Affected Scenarios:

• Scenario 1: service = "databricks" + networking_method = "PrivateLink" + cloud_provider = "AZURE"
• Scenario 2: Any destination with private_link_id or networking_method set when toggling run_setup_tests

[fivetran-renat-sh]

Hi @jhiza !

My apologies for slow response.

• Regarding 1st issue, please remove config.server_host_name from Terrafrom config because it is anyway getting overwritten with a host from the private link (Fivetran API was fixed this week, to allow for skipping config.server_host_name in case of PrivateLink). And preferably skip config.cloud_provider as well. Like:

resource "fivetran_destination" "databricks_pl" {
  group_id             = fivetran_group.example_group.id
  service              = "databricks"
  time_zone_offset     = "0"
  region               = "AZURE_EASTUS"
  trust_certificates   = true
  trust_fingerprints   = true
  daylight_saving_time_enabled = true
  run_setup_tests      = false
  networking_method    = "PrivateLink"
  private_link_id      = "your_private_link_id"

  config {
    auth_type             = "PERSONAL_ACCESS_TOKEN"
    catalog               = "your_catalog"
    server_host_name      = "adb-xxxxxxxxxxxxxxx.xx.azuredatabricks.net"
    port                  = 443
    http_path             = "/sql/1.0/warehouses/your_warehouse"
    personal_access_token = "your_token"
  }
}

• 2nd issue should be fixed now in v1.9.27 (release notes)

[carobitap]

@fivetran-renat-sh
I followed the suggested approach of removing server_host_name from the config, but I’m still seeing incorrect behavior after apply.

What I expected:
When server_host_name is omitted, the provider should fall back to the correct Databricks hostname (e.g. adb-xxxxx.azuredatabricks.net) based on the destination configuration.

What actually happens:
The provider appears to reuse the previously stored value from state instead of resolving a correct/default hostname.
When networking_method = "PrivateLink" is set, the setup test overwrites server_host_name in state with the PrivateLink URL returned in the response (e.g. pls-...fivetran.com).
This replaces the valid Databricks hostname with a PLS hostname.

Problem:
On subsequent plans/applies, the setup test runs against this PLS hostname directly, which fails DNS resolution (since it’s not meant to be used as a direct JDBC endpoint). The destination then remains stuck in a broken state.

[fivetran-renat-sh]

Hi @carobitap !

Thank you for the info.

Please create a support ticket at Fivetran support portal: https://support.fivetran.com/hc/en-us/requests/new

With a Terraform config attached, as it might require to check specific details for a fix.