bundle run on an app fails with "not in RUNNING state" when the app's compute is UPDATING

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

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

@andrewnester がすでに取り組んでいます。

2026年11月11日 から。

  • #7460 @andrewnester による — オープン

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
76/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
go
領域
cli

調査の方向性

Start with bundle/run/app.go, especially appRunner.Run, which the issue identifies as the failing state check. Trace how it handles compute states and how WaitGetAppActive responds when compute stops during startup. Done when bundle run <app> waits through transient states and handles a STARTING compute that returns to STOPPED, with tests covering these cases.

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

説明

Bug DABs
Describe the issue

databricks bundle run <app> can fail on a newly created app because it checks the app's compute state only once. It starts a compute that is STOPPED or ERROR and waits on one that is STARTING. In any other state, such as UPDATING, it tries to deploy straight away and fails with "not in RUNNING state". The relevant code is bundle/run/app.go, appRunner.Run. It is the same in v1.16.1 and v1.25.0.

There is a related case in the same code. A new app's compute can go from STARTING back to STOPPED on its own. If bundle run reads it during STARTING, it waits for ACTIVE (WaitGetAppActive), and that wait fails when the compute stops instead.

Steps to reproduce the behavior

The failure is intermittent, because it depends on the compute's state at the moment bundle run reads it.

  1. Define an app in a bundle, with a job that runs before the app is started.
  2. Run databricks bundle deploy -t <target>, which creates the app.
  3. Run the job with databricks bundle run <job> -t <target>. In our case it took about 50 seconds.
  4. Run databricks bundle run <app> -t <target>.
  5. Sometimes the compute is UPDATING at step 4, and the command fails. In our case this happened in 1 of 4 deploys of a new app.

Polling databricks apps get <app> -o json every 3 seconds during a new-app deploy showed the compute go from STARTING to STOPPED about 20 seconds after bundle deploy created the app.

Expected Behavior

bundle run <app> waits until the compute settles in ACTIVE, STOPPED or ERROR before it starts or deploys the app. It should tolerate transient states such as UPDATING and STOPPING, and a STARTING compute that ends STOPPED.

Actual Behavior
✓ Getting the status of the app my-app
✓ App is in UNAVAILABLE state
✓ App compute is in UPDATING state
Error: Cannot deploy app my-app as it is not in RUNNING state. Please start the app first.
OS and CLI version

Databricks CLI v1.16.1 on Linux, run non-interactively in a deployment pipeline as a service principal, against an AWS workspace. The code path is unchanged in v1.25.0.

Is this a regression?

Not known. We have only run v1.16.1. bundle/run/app.go is the same in v1.16.1 and v1.25.0.

Debug Logs

We don't have a debug-level log of a failing run. The failure is intermittent, and it happened in an unattended pipeline. The output above is the command's normal output, with the app name redacted.

Workaround we use: before bundle run <app>, poll databricks apps get <app> -o json until .compute_status.state is ACTIVE, STOPPED or ERROR, or the status is absent, with a time limit. Then run bundle run <app>.

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

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

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

databricks/cli のほかの issue

databricks/cli の issue をすべて見る

似ている issue

Go の issue をもっと見る

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

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