Provider allows invalid environment schema/dataset names without validation

[TimKlense]

Describe the bug / feature request

The dbt Cloud Terraform provider lets you create credentials/environments with invalid schema (or dataset) names. The apply succeeds, but downstream operations (dbt runs, object creation) fail at runtime due to the invalid name. This likely needs input validation in the provider at plan/apply time.

Error message

N/A - Validation checks needed

Resource configuration

The relevant resource configuration (sanitised so it doesn't contain sensitive data)

Likely affected resources (tbh I don't know the full list of validation checks for each adapter & schema. So someone would need to verify.)

• dbtcloud_databricks_credential.schema
• dbtcloud_snowflake_credential.schema
• dbtcloud_bigquery_credential.dataset
• dbtcloud_redshift_credential.default_schema
• dbtcloud_postgres_credential.default_schema
• dbtcloud_starburst_credential.schema
• dbtcloud_teradata_credential.schema
• dbtcloud_synapse_credential.schema
• dbtcloud_fabric_credential.schema
• dbtcloud_athena_credential.schema

Minimal TF config # take note of the "/" in the schema for dbtcloud_databricks_credential

terraform {
  required_providers {
    dbtcloud = {
      source  = "dbt-labs/dbtcloud"
      version = "~> 1.0"
    }
  }
}

provider "dbtcloud" {
  account_id = var.dbt_account_id
  token      = var.dbt_token
  host_url   = var.dbt_host_url
}

resource "dbtcloud_project" "example" {
  name = "Validation Test"
}

resource "dbtcloud_databricks_credential" "invalid_schema" {
  project_id   = dbtcloud_project.example.id
  token        = "placeholder"
  schema       = "dbt_prod_schema_databricks_user/token" # invalid: contains '/'
  adapter_type = "databricks"
  catalog      = "main"
}

Steps to reproduce

1. Apply the configuration above.
2. Observe that Terraform apply succeeds and the credential/resource is created in dbt Cloud.
3. Attempt to run a job that uses this credential/environment.
4. The run fails at runtime due to the invalid schema name

No validation error at plan/apply. The invalid value is accepted and only surfaces as a runtime failure later.

Note: here's what dbt Cloud displays as a validation check/msg

It's possible you'd want to check their entire validation logic for the form (if you'd want to match their logic)

Expected behavior

• The provider should validate schema/dataset names per adapter and fail early with a helpful error message during plan/apply when the value is invalid.

Config (please complete the following information):

• dbt Cloud provider version: 1.2.1

Additional context

Add any other context about the problem here.

[b-per]

Isn't this something that we should handle on the API side?
(it's possible to add validation in TF, but it feels like the API needs those checks as well)

[TimKlense]

Totally agree the API should be the source of truth here. I opened this from the TF side because that’s where I hit it first, but I think this should be handled in both areas

• API: enforce adapter-specific schema/dataset validation and return clear 4xx errors & err messages. Bonus: that protects every client (UI, API, TF, CLI) and avoids invalid states - all across the board.
• TF: add conservative, early checks (length/simple regex per adapter) to catch obvious mistakes at plan time and improve ux, but still defer to the API for the authoritative decision and surface API errors

I'll mark this as a request so others can discover it and share their experience if they encounter similar issues

[adrianburusdbt]

The goal is to have 1 to 1 behavior with the UI, so I'm curious if this validation is done there or not. If it is, we can consider doing something similar, but in principle, this is an API check.

[TimKlense]

The goal is to have 1 to 1 behavior with the UI, so I'm curious if this validation is done there or not. If it is, we can consider doing something similar, but in principle, this is an API check.

Thanks! The frontend does have a validation check today (see the screenshot in my original post), but the API currently allows these values through