Description

databricks_grants does not work with provider_config { workspace_id = ... } when using an account-level provider. The resource fails with:

Error: cannot create grants: invalid Databricks Workspace configuration - host is not a workspace host

Other resources like databricks_catalog and databricks_schema work correctly with the same pattern.

Configuration to reproduce

provider "databricks" {
  alias      = "account"
  host       = "https://accounts.cloud.databricks.com"
  account_id = var.account_id
}

resource "databricks_mws_workspaces" "this" {
  for_each     = local.workspaces
  provider     = databricks.account
  account_id   = var.account_id
  workspace_name = each.key
  aws_region     = "eu-central-1"
  compute_mode   = "SERVERLESS"
  pricing_tier   = "ENTERPRISE"
}

# ✅ Works — databricks_catalog uses WorkspaceClientUnifiedProvider for all API calls
resource "databricks_catalog" "this" {
  provider      = databricks.account
  name          = "my_catalog"
  force_destroy = true
  provider_config {
    workspace_id = databricks_mws_workspaces.this["my-workspace"].workspace_id
  }
}

# ✅ Works — databricks_schema also uses WorkspaceClientUnifiedProvider correctly
resource "databricks_schema" "this" {
  provider     = databricks.account
  catalog_name = "my_catalog"
  name         = "my_schema"
  provider_config {
    workspace_id = databricks_mws_workspaces.this["my-workspace"].workspace_id
  }
}

# ❌ Fails — databricks_grants ignores provider_config for actual API calls
resource "databricks_grants" "catalog" {
  provider = databricks.account
  catalog  = databricks_catalog.this.name

  grant {
    principal  = "my-group"
    privileges = ["USE_CATALOG"]
  }

  provider_config {
    workspace_id = databricks_mws_workspaces.this["my-workspace"].workspace_id
  }
}

Root cause

In catalog/resource_grants.go, the Create/Update/Delete functions call WorkspaceClientUnifiedProvider(ctx, d) but only use the returned client w for metastore validation. The actual grants API call uses a separate WorkspaceClient() call that ignores provider_config:

// Step 1: Gets correct workspace-scoped client
w, err := c.WorkspaceClientUnifiedProvider(ctx, d)
// Step 2: Only used for metastore validation
err = validateMetastoreId(ctx, w, d.Get("metastore").(string))
// Step 3: Gets a NEW client that ignores provider_config — THIS IS THE BUG
ws, err := c.WorkspaceClient()
// Step 4: Actual API call uses the wrong client
unityCatalogPermissionsAPI := permissions.NewUnityCatalogPermissionsAPI(ctx, ws)

The Read function never calls WorkspaceClientUnifiedProvider at all.

By contrast, resource_catalog.go correctly uses the unified provider client for all operations:

w, err := c.WorkspaceClientUnifiedProvider(ctx, d)
ci, err := w.Catalogs.Create(ctx, request)  // same client used for API call

History

• PR [Internal] Add remaining resources to unified provider #5341 (merged 2026-02-06) added provider_config support to databricks_grants, but only wired it up for metastore validation, not for the permissions API.
• PR Handle error during WorkspaceClient() creation in databricks_grant and databricks_grants resources #5403 (merged 2026-02-17, fixing [ISSUE] Issue with databricks_grants resource #5360) added explicit c.WorkspaceClient() calls with error handling, cementing the bug.

Suggested fix

Pass the w client from WorkspaceClientUnifiedProvider to NewUnityCatalogPermissionsAPI instead of creating a separate client via WorkspaceClient(). All CRUD functions should match the pattern used by resource_catalog.go.

Impact

This effectively makes provider_config unusable for managing grants from an account-level provider — which is our primary use case for provider_config. Users can create catalogs and schemas via the account provider, but cannot assign permissions to them without a separate workspace-level provider, defeating the purpose of the unified provider pattern.

Environment

• Terraform: v1.14.7
• Provider: databricks/databricks >= 1.49.0 (tested with latest)
• Platform: AWS (SAP Databricks Cloud, serverless workspaces)