Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#5,950 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
go, terraform
Lĩnh vực
cli, infrastructure

Hướng nghiên cứu

Bắt đầu với các test trong acceptance/bundle/variables/* và tái hiện cấu hình thông qua bundle validate và bundle deploy bằng terraform engine. So sánh .databricks/bundle//terraform/bundle.tf.json được tạo ra với yêu cầu trực tiếp tới engine, sau đó lần theo nơi chuỗi rỗng thay đổi trước khi tạo job. Hoàn tất có nghĩa là đường dẫn terraform tạo job với tham số rỗng hoặc báo cáo lỗi validation rõ ràng, đồng thời coverage của acceptance phân biệt được trường hợp này với direct engine.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Go
Star
396
Fork
233
Merge trung bình
1 ngày 12 giờ
Pull request đã merge (30 ngày)
283

Chuẩn bị môi trường

Chúng tôi chưa kiểm tra các tệp thiết lập môi trường của dự án này. Hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của databricks/cli

Tất cả issue của databricks/cli

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.