[ISSUE] `databricks_permissions` still produces "inconsistent final plan" on the access_control set (SQL warehouse, v1.118.0, after #5091)

[atipapp]

Configuration

A databricks_permissions on a SQL warehouse whose access_control mixes a static group block with dynamic service-principal blocks:

resource "databricks_permissions" "sql_endpoint_usage" {
  sql_endpoint_id = databricks_sql_endpoint.this.id

  access_control {
    group_name       = "users"
    permission_level = "CAN_USE"
  }

  dynamic "access_control" {
    for_each = var.service_principal_application_ids # set of SP application IDs
    content {
      service_principal_name = access_control.value
      permission_level       = "CAN_USE"
    }
  }
}

Expected Behavior

Apply succeeds; the access_control set is consistent between plan and apply.

Actual Behavior

Intermittently, apply fails with:

Error: Provider produced inconsistent final plan

When expanding the plan for module….databricks_permissions.sql_endpoint_usage to include
new values learned so far during apply, provider produced an invalid new value for
.access_control: planned set element cty.ObjectVal(map[string]cty.Value{
  "group_name":cty.StringVal("users"), "permission_level":cty.StringVal("CAN_USE"),
  "service_principal_name":cty.NullVal(cty.String), "user_name":cty.NullVal(cty.String)})
does not correlate with any element in actual.

Steps to Reproduce

1. terraform apply the config above as part of a larger plan.
2. Intermittently it fails on the permissions resource with the above error.
3. Re-run terraform apply — it usually succeeds.

Terraform and provider versions

• Terraform >= 1.12
• databricks/databricks provider 1.118.0

Is it a regression?

The same "inconsistent final plan in the Permissions resource" was addressed in #5091 (merged 2025-10-22), which is included in v1.118.0 (released 2026-06-17) — yet it still occurs here. #5091's description notes it was an attempt to fix an intermittent issue, so this looks like an incomplete fix for the SQL-warehouse / users-group case. Older related closed issues: #2608, #2159.

Debug Output

The block above is what the apply surfaces; happy to attach a TF_LOG=DEBUG gist on request.

Important Factoids

• Intermittent — some applies fail, a re-run passes.
• access_control is a set mixing a static group_name = "users" element and dynamic service_principal_name elements; the element that fails to correlate is the static users/CAN_USE one.

Would you like to implement a fix?

Happy to help validate/test; this looks like a provider-internal set-consistency issue (likely the same root cause #5091 targeted), so deferring to maintainers on the approach.