clusters start: no-op when cluster isn't TERMINATED - #6344
Conversation
Waiting for approvalBased on git history, these people are best suited to review:
Eligible reviewers: Suggestions based on git history. See OWNERS for ownership rules. |
`databricks clusters start` returns an INVALID_STATE API error if the target cluster is already RUNNING/PENDING/RESTARTING/RESIZING, even though the command's own help text says "If the cluster is not currently in a TERMINATED state, nothing will happen." Wrap the generated start command's RunE (mirrors the same INVALID_STATE handling already used in bundle/direct/dresources/cluster.go) so that error is swallowed and treated as a successful no-op instead. Fixes databricks#1372 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
6717e6c to
4430870
Compare
|
An authorized user can trigger integration tests manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
|
@janniklasrose the reviewer bot pointed at you for |
Changes
databricks clusters startreturns an API error if the target cluster isn't TERMINATED (e.g. it's already RUNNING). The command's own help text says otherwise: "If the cluster is not currently in a TERMINATED state, nothing will happen." This PR makes the command match that text: onINVALID_STATE, it prints a short message and exits 0 instead of failing.Why
Fixes #1372. Scripts that call
clusters startto make sure a cluster is up (a common idempotent pattern) currently have to special-case this error themselves. A previous attempt at this fix (#2947) took a similar approach but stalled and auto-closed without maintainer feedback.Tests
Added
cmd/workspace/clusters/overrides_test.go, covering:INVALID_STATEis swallowed and the command returns nilgo build ./cmd/workspace/clusters/...andgo vet ./cmd/workspace/clusters/...pass. I don't have a Databricks workspace to run this against a live already-running cluster, so I'd appreciate a maintainer or CI check on that path.