Skip to content

Make clusters start succeed when the cluster is already running - #6288

Draft
TangoEnSkai wants to merge 1 commit into
databricks:mainfrom
TangoEnSkai:clusters-start-idempotent
Draft

Make clusters start succeed when the cluster is already running#6288
TangoEnSkai wants to merge 1 commit into
databricks:mainfrom
TangoEnSkai:clusters-start-idempotent

Conversation

@TangoEnSkai

@TangoEnSkai TangoEnSkai commented Aug 17, 2026

Copy link
Copy Markdown

Changes

databricks clusters start on a cluster that is already running now reports success and prints the cluster, instead of failing with Cluster <id> is in unexpected state Running.. Any other INVALID_STATE rejection (a terminating cluster, for example) is still returned unchanged.

The test server now models the API's INVALID_STATE rejection of clusters/start for a cluster that is not terminated; it previously accepted the call in any state.

Fixes #1372.

Why

The command's own help text states "If the cluster is not currently in a TERMINATED state, nothing will happen", but the API rejects the request, so a script that just wants the cluster up has to match on the error message. The direct engine already treats an already-running cluster as a no-op (bundle/direct/dresources/cluster.go), so this aligns the standalone command with both the documented contract and bundle behavior.

The check is deliberately narrow: it re-reads the cluster after INVALID_STATE and only swallows the error when the state is RUNNING. A cluster that is PENDING or RESTARTING still errors out, because succeeding there would mean waiting for a state transition rather than reporting a no-op.

Tests

New acceptance test acceptance/cmd/workspace/clusters-start, covering both an already-running cluster and a terminated one. Reverting only the cmd/workspace/clusters change makes it fail with the exact error from the issue:

>>> [CLI] clusters start [CLUSTER_ID]
Error: Cluster [CLUSTER_ID] is in unexpected state RUNNING.

Exit code: 1

./task fmt, ./task checks and ./task lint are clean. ./task test passes locally except for bundle/templates-machinery/supported-url, which fails the same way on an unmodified origin/main checkout here because my network path answers the intentionally invalid host with a proxy error instead of a DNS failure.

This PR was written by Claude Code, then reviewed and tested by me.

The API rejects a start request for a cluster that is not TERMINATED with
INVALID_STATE, while the command's help states that nothing happens in that
case. Re-read the cluster on INVALID_STATE and report success when it is
already RUNNING; every other rejection is returned unchanged.

The test server accepted clusters/start in any state, so it could not express
this; it now returns the same INVALID_STATE error as the API.

Fixes databricks#1372

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@TangoEnSkai
TangoEnSkai force-pushed the clusters-start-idempotent branch from f574a7a to 06ef290 Compare August 17, 2026 13:16
@github-actions

Copy link
Copy Markdown
Contributor

An authorized user can trigger integration tests manually by following the instructions below:

Trigger:
go/deco-tests-run/cli

Inputs:

  • PR number: 6288
  • Commit SHA: 06ef29073271ca57d26f7699fcc1e13d7d28f20b

Checks will be approved automatically on success.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

databricks clusters start fails if cluster is already running, despite documentation to the contrary

1 participant