Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#5,950 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
go, terraform
領域
cli, infrastructure

調査の方向性

acceptance/bundle/variables/* テストから始め、terraform engine を使用して bundle validate と bundle deploy を通じて設定を再現します。生成された .databricks/bundle//terraform/bundle.tf.json を direct-engine request と比較し、その後、job の作成前に空文字列がどこで変化するのかを追跡します。terraform path が空のパラメーターを指定して job を作成するか、明確な validation error を報告し、acceptance coverage がそれを direct engine と区別できれば完了です。

索引モデルが issue の本文から書いたものです。

説明

Bug DABs
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.

主要言語
Go
スター
396
フォーク
233
平均マージ
1日 12時間
マージ済み PR（30日）
283

環境構築

このプロジェクトの環境構築ファイルはまだ確認していません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

databricks/cli のほかの issue

databricks/cli の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。