bundle deploy panics with `parameters[<nil>] is not a string` when a task parameter is an empty string (terraform engine)

從 acceptance/bundle/variables/* 測試開始，並使用 terraform engine 透過 bundle validate 和 bundle deploy 重現該設定。將產生的 .databricks/bundle//terraform/bundle.tf.json 與 direct-engine request 進行比較，接著追蹤空字串在 job 建立前於何處發生變化。完成的標準是 terraform 路徑使用空參數建立 job，或回報清楚的 validation error，且 acceptance 覆蓋能將其與 direct engine 區分開來。

Describe the issue

If a task's parameters list contains an element that resolves to an empty string, bundle validate passes but bundle deploy fails while creating the job, with a panic surfaced from the terraform provider:

Error: cannot create job: panic: task: spark_python_task: parameters: task.0.spark_python_task.0.parameters[<nil>] is not a string

The usual way to end up here is a bundle variable that is deliberately empty in some targets, for example a per-developer table prefix that is blank in shared environments:

parameters:
  - "--suffix"
  - ${var.run_suffix}   # empty string in shared targets

While narrowing this down we found two things that locate the problem:

• The generated .databricks/bundle/<target>/terraform/bundle.tf.json is well formed: the parameter renders as "", not null. The empty string becomes a null somewhere between terraform and the provider's schema read layer, and the provider panics instead of returning an error.
• The direct engine (DATABRICKS_BUNDLE_ENGINE=direct) deploys the identical configuration fine, and the job is created with the empty string parameter.

Because the provider only ever sees the generated terraform configuration, the variable itself is not essential to the bug. A parameters element written as a literal empty string produces the same file and the same crash. Variables matter only in that they are the usual way a real configuration ends up with an empty element in one target and not another.

We hit this four times over two months in our own deployment pipelines (spark_python_task and python_wheel_task) before we spotted the pattern, because validate passes and the crash only shows up in whichever target leaves the variable empty.

Configuration

bundle:
  name: empty-var-param-repro

variables:
  run_suffix:
    description: Optional suffix appended to job parameters
    default: ""

resources:
  jobs:
    demo_job:
      name: demo-job
      tasks:
        - task_key: main
          spark_python_task:
            python_file: ./src/main.py
            parameters:
              - "--suffix"
              - ${var.run_suffix}
          new_cluster:
            spark_version: 15.4.x-scala2.12
            node_type_id: i3.xlarge
            num_workers: 1

(./src/main.py can be any file.)

Steps to reproduce the behavior

1. databricks bundle validate -o json passes; the parameters resolve to ["--suffix", ""]
2. databricks bundle deploy
3. Deploy fails during job creation:

Deploying resources...
Error: terraform apply: exit status 1

Error: cannot create job: panic: task: spark_python_task: parameters: task.0.spark_python_task.0.parameters[<nil>] is not a string

  with databricks_job.demo_job,
  on bundle.tf.json line 45, in resource.databricks_job.demo_job:
  45:       }

With DATABRICKS_BUNDLE_ENGINE=direct the same bundle deploys successfully and jobs/create receives ["--suffix", ""].

Expected Behavior

Either the job is created with the empty string parameter, matching the direct engine and what the Jobs API accepts, or the CLI reports a clean error that names the offending value and its config path, ideally at validate time.

Actual Behavior

bundle validate passes, then bundle deploy crashes job creation with the provider panic above.

OS and CLI version

Reproduced on macOS against a CLI built from main (commit 84a9fe717, 2026-07-16, bundled terraform provider 1.121.0). We also saw it on released versions we used between May and July 2026 (v1.1.0 through v1.6.0 era).

Is this a regression?

Not as far as we know. The direct engine handles the same configuration correctly.

Debug Logs

We can attach these if useful. The repro is hermetic: we run it as an acceptance test in the style of acceptance/bundle/variables/* against the local test server, where the direct engine variant passes and the terraform variant reproduces the panic.

The root cause looks like it sits in the terraform provider layer rather than in the CLI's own output, but bundle deploy is where users hit it, so we are filing it here first. Happy to move or cross-file it to terraform-provider-databricks if that is the better home.