lakebox: explicitly start stopped sandbox before ssh#5429
Merged
akshaysingla-db merged 2 commits intoJun 4, 2026
Merged
Conversation
Mirrors the "creating" treatment so transient states are visually distinct from terminal ones in `list` and `status` output. Co-authored-by: Isaac
Replace the bare warning "Starting <id>… (may take a few minutes)" with an explicit api.start + waitForRunning sequence before exec'ing ssh. The SSH gateway already auto-starts a stopped sandbox on connect, but that path is opaque — ssh just hangs for minutes with no progress — and races the cold-start timeout. Driving the start ourselves gives the user a visible spinner with elapsed time and a deterministic timeout (the same one `databricks lakebox start` uses). The new ensureRunning helper also handles already-transitioning states (Creating, Starting): it skips the start RPC and just polls. Co-authored-by: Isaac
Contributor
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. |
41d1215
into
databricks:demo-lakebox
10 of 25 checks passed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Replaces the bare
warn(ctx, "Starting <id>…")notice inlakebox sshwith an explicitapi.start+waitForRunningsequence before exec-ing ssh.Why
The user-principal that triggers the start should be the user, not the gateway. Today the SSH gateway implicitly starts a stopped sandbox on connect, which means audit trails, billing attribution, and any server-side hooks see the gateway service principal as the actor — not the human who actually wanted the sandbox up. Routing the start through
api.startfrom the CLI carries the workspace credential of the running user, so the StartSandbox RPC is attributed to them.Nice-to-haves that fall out for free:
databricks lakebox startuses) rather than racing the SSH gateway's cold-start window.Creating,Starting) get polled cleanly via the sameensureRunninghelper — no double-start RPC.sandboxEntrywe get back lets us refresh the cachedGatewayHostif it changed during the start.User-visible change
Before:
After:
Test plan
go test ./cmd/lakebox/...passesgo build ./...cleanThis pull request and its description were written by Isaac.