Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#5,950 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Pouca atividade
Stack de tecnologia
go, terraform
Domínio
cli, infrastructure

Direção de pesquisa

Comece pelos testes em acceptance/bundle/variables/* e reproduza a configuração usando bundle validate e bundle deploy com o terraform engine. Compare o .databricks/bundle//terraform/bundle.tf.json gerado com a requisição ao direct engine e, em seguida, rastreie onde a string vazia muda antes da criação do job. Está concluído quando o caminho do terraform cria o job com o parâmetro vazio ou reporta um erro de validação claro, e a cobertura de acceptance o diferencia do direct engine.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Go
Estrelas
403
Forks
244
Merge médio
1d 12h
PRs com merge (30d)
286

Preparar o ambiente

  • Inclui um Dockerfile ou arquivo Docker Compose
  • Tem um modelo de pull request
  • Sem guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de databricks/cli

Todas as issues de databricks/cli

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.