Use X-Databricks-Workspace-Id for workspace routing#1688
Open
Divyansh-db wants to merge 2 commits into
Open
Conversation
Regenerated from the gosdkv0 template change in databricks-eng/universe#1955306, which renames the workspace routing header emitted on SPOG/unified-host requests from `X-Databricks-Org-Id` to `X-Databricks-Workspace-Id`. This is the M1 piece of the "DECO + Unified Workspace Addressing" initiative. The diff is mechanical: 944 swaps across 34 generated files, no behavioral change. The value still comes from `Config.WorkspaceID` and emission is still gated on the operation being workspace-scoped (`!Service.IsAccounts`). Co-authored-by: Isaac Signed-off-by: Divyansh Vijayvergia <divyansh.vijayvergia@databricks.com>
Companion to the regenerated code: the generator only touched the OpenAPI-spec backed `service/*/impl.go` files. This change updates the hand-written sites that emit or parse the same SPOG routing header on workspace-scoped API calls: - `service/iam/ext_impl.go`, `service/sharing/ext_api.go`, `service/workspace/ext_utilities.go`: swap `X-Databricks-Org-Id` → `X-Databricks-Workspace-Id` in the manually-written header injection (these files extend generated services with hand-written endpoints/wrappers and weren't covered by the codegen pass). - `workspace_functions.go`: `CurrentWorkspaceID` now sends and reads the new header on `/api/2.0/preview/scim/v2/Me`; doc comments updated. - `workspace_functions_test.go`: tests assert the new header name; function names renamed (`OrgIdHeader` → `WorkspaceIdHeader`) so the test names reflect what they cover. - `config/config.go`: widen the `WorkspaceID` doc comment to note the value can now be a classic numeric workspace ID *or* a CPDR connection ID (the server disambiguates). Field name, type, and env var (`DATABRICKS_WORKSPACE_ID`) unchanged. - `NEXT_CHANGELOG.md`: entry under Internal Changes. POPP keeps accepting the legacy `X-Databricks-Org-Id` for rollback safety, so this is safe to land any time after M0 platform support is fully rolled out. Co-authored-by: Isaac Signed-off-by: Divyansh Vijayvergia <divyansh.vijayvergia@databricks.com>
|
If integration tests don't run automatically, an authorized user can run them manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
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
Workspace-scoped API calls now identify the target workspace via the
X-Databricks-Workspace-Idheader instead ofX-Databricks-Org-Id. The value source is unchanged: it still comes fromConfig.WorkspaceID(or theDATABRICKS_WORKSPACE_IDenvironment variable).Why
On unified Databricks hosts that serve multiple workspaces, the SDK sends a routing header on every workspace-scoped HTTP request so the gateway can dispatch it to the correct workspace. Until now that header was
X-Databricks-Org-Id.The Databricks platform is consolidating workspace addressing onto a single header,
X-Databricks-Workspace-Id, which accepts a broader range of workspace identifier formats and replaces the older single-purpose channels going forward. The previous header continues to be accepted by the platform, so older SDK versions keep working, but new SDK versions should use the new name.This PR is the Go SDK's part of that migration.
What changed
Interface changes
None.
Config.WorkspaceIDkeeps the same field name, type (string), and environment variable (DATABRICKS_WORKSPACE_ID). The doc comment is widened to note that the value may now be either a classic numeric workspace ID or another workspace identifier format that the server understands.Behavioral changes
X-Databricks-Org-Id. They now sendX-Databricks-Workspace-Id(with the same value, gated onConfig.WorkspaceIDbeing non-empty). Account-scoped requests are unaffected.WorkspaceClient.CurrentWorkspaceIDreads the workspace ID from theX-Databricks-Workspace-Idresponse header on/api/2.0/preview/scim/v2/Meinstead ofX-Databricks-Org-Id.Internal changes
service/*/impl.goandinternal/testspecs/service/*/impl.gofrom the corresponding generator template change: 34 files, 944 line swaps, no logic change.service/iam/ext_impl.go,service/sharing/ext_api.go,service/workspace/ext_utilities.go, andworkspace_functions.go.TestCurrentWorkspaceID*test functions so the names match the new header.How is this tested?
make fmt,make lint, andmake testall pass locally. Full unit suite is green (1404 passed, 103 skipped).workspace_functions_test.gotests cover both sides of the new header (request emission and response parsing on theMeprobe).service/*/impl.gois exclusively the header literal swap; no collateral changes.