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

Open
  • Is something wrong?
#7,451 0 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@andrewnester is already working on this.

Since Nov 11, 2026.

  • #7460 by @andrewnester — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go
Domain
cli

Research direction

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.

Written by the indexing model from the issue text.

Description

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

Dominant language
Go
Stars
427
Forks
267
Avg merge
2d 1h
Merged PRs (30d)
233

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from databricks/cli

All issues in databricks/cli

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.