Resolve workspace IDs as strings at all CLI consumers#5379
Open
Divyansh-db wants to merge 2 commits into
Open
Conversation
The CLI calls CurrentWorkspaceID on the workspace client in five places.
The SDK helper returns (int64, error) and reads the value from the
X-Databricks-Org-Id response header on /api/2.0/preview/scim/v2/Me. Every
caller then formats the int64 back to a string at its own boundary, or
embeds it with %d in the case of experimental/ssh's driver-proxy URL.
This commit introduces auth.ResolveWorkspaceID, a small helper that:
1. Returns w.Config.WorkspaceID if set (and not the CLI-only "none"
sentinel) — no API call.
2. Otherwise calls w.CurrentWorkspaceID and stringifies the result.
The fast path is also a small performance win — the workspace ID is
already configured in the common SPOG case (set via --workspace-id,
DATABRICKS_WORKSPACE_ID, workspace_id in .databrickscfg, or ?w=/?o= on
a host URL), so resolving it no longer requires hitting /Me when the
value is already known.
Migrating the five consumers makes the in-CLI workspace ID flow string-
typed end-to-end. As a side effect, non-numeric workspace identifiers
(e.g. connection-style IDs that the new X-Databricks-Workspace-Id
header accepts) now flow cleanly through these consumers when
configured by the user.
Consumers migrated:
- databricks experimental open (cmd/experimental/workspace_open.go)
- databricks bundle summary URL builder
(bundle/config/mutator/initialize_urls.go)
- databricks apps run-local (cmd/apps/run_local.go)
- databricks experimental ssh driver-proxy URL
(experimental/ssh/internal/client/websockets.go)
- databricks experimental ssh cluster-metadata fetch
(experimental/ssh/internal/client/client.go)
Downstream signatures widened from int64 to string:
- workspaceurls.BuildResourceURL, workspaceurls.workspaceBaseURL
- runlocal.Config.WorkspaceID, runlocal.NewConfig
- The two fmt.Sprintf calls in experimental/ssh swap %d -> %s for the
workspace ID slot. The /driver-proxy-api/o/<id>/... URL keeps its
legacy "o" path segment — that's a separate platform-side URL
scheme decision from the ?o=/?w= query parameter migration.
Out of scope:
- libs/auth/introspect.go declares WorkspaceID int64 on the
/api/2.0/tokens/introspect response. Different endpoint, separate
follow-up.
- cmd/auth/login.go's workspace picker reads WorkspaceId int64 from
the SDK's Workspaces.List response — upstream SDK schema, not
fixable in the CLI alone.
Behavior preserved:
- Configured workspace ID: identical value flows downstream.
- Resolved-from-/Me path: SDK still parses the response header as
int64; the helper just stringifies it.
- Acceptance tests pass unchanged.
The ResolveWorkspaceID helper's fast path returns the already-configured
cfg.WorkspaceID without hitting /api/2.0/preview/scim/v2/Me. This is the
intended behavior — saves an API call when the workspace ID is already
known — but the bundle/user_agent/simple golden was recorded with the
old behavior where bundle summary always made the /Me call.
Regenerated via ./task test-update. Diff is a clean removal of the
/Me request from out.requests.summary.{direct,terraform}.json, plus the
matching count in output.txt. No other behavior change.
Collaborator
|
Commit: ae92528 |
simonfaltum
approved these changes
May 30, 2026
Member
simonfaltum
left a comment
There was a problem hiding this comment.
Reviewed the current head. My earlier concern about ?w= / string workspace ID parsing is covered by #5373, so this PR looks good from my side.
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
The CLI calls `CurrentWorkspaceID` on the workspace client in five places to obtain the workspace ID. The SDK helper returns `(int64, error)` and reads the value from the `X-Databricks-Org-Id` response header on `/api/2.0/preview/scim/v2/Me`, parsing with `strconv.ParseInt`. Every consumer then formats the int64 back to a string at its own boundary — or, in two cases under `experimental/ssh`, embeds it directly with `%d`.
This PR introduces a small helper that returns the workspace ID as a string and short-circuits the API call when the workspace ID is already configured on the client, and migrates the five consumers to use it. As a side effect, the in-CLI workspace ID flow becomes string-typed end-to-end, so non-numeric workspace identifiers (e.g. connection-style IDs) flow through cleanly when configured.
The helper
`libs/auth.ResolveWorkspaceID(ctx, w)`:
The fast path is also a small performance win — the workspace ID is already configured in the common SPOG case (set via `--workspace-id`, `DATABRICKS_WORKSPACE_ID`, `workspace_id` in `.databrickscfg`, or `?w=`/`?o=` on a host URL), and the existing code unconditionally hit `/Me` to resolve the same value.
Consumer migrations
Five call sites switch from `CurrentWorkspaceID` to `ResolveWorkspaceID`:
Downstream signatures widen from int64 to string
Behavior change summary
Out of scope
Test plan