Wire profile name through CLI ToOAuthArgument for profile-based cache keys#4562
Merged
simonfaltum merged 1 commit intomainfrom Feb 22, 2026
Merged
Wire profile name through CLI ToOAuthArgument for profile-based cache keys#4562simonfaltum merged 1 commit intomainfrom
simonfaltum merged 1 commit intomainfrom
Conversation
The SDK supports profile-based OAuth token cache keys via NewProfile* constructors, but the CLI always used NewBasic* constructors which never pass the profile name through. This meant profile-based cache keys were never used end-to-end. Add a Profile field to AuthArguments and switch ToOAuthArgument() from NewBasic* to NewProfile* constructors. Wire the profile name from cmd/auth/token.go and cmd/auth/login.go into AuthArguments before calling ToOAuthArgument(). When Profile is empty (no profile specified), behavior is unchanged since NewProfile* with empty string falls back to host-based keys.
Collaborator
|
Commit: b592eb6
15 interesting tests: 7 KNOWN, 7 SKIP, 1 flaky
Top 20 slowest tests (at least 2 minutes):
|
cc2ddb3 to
b592eb6
Compare
renaudhartert-db
approved these changes
Feb 21, 2026
github-merge-queue bot
pushed a commit
that referenced
this pull request
Feb 23, 2026
…4574) ## Why Profile-based cache keys landed on main (PR #4562). Now `auth token --profile X` uses the profile name as the token cache key. However, when using `--host H` or a positional host arg, there's no profile resolution — the command goes straight to host-based cache lookup. If two profiles share the same host, whoever logged in last wins. There's also no way to pass a profile name as a positional arg (`databricks auth token myprofile` gets treated as a host and fails). ## Changes - **Positional profile name detection**: `databricks auth token myprofile` resolves positional args as profile names first, falling through to host treatment only if no profile matches. This works for dotted profile names like `default.dev` too. - **Host ambiguity detection**: `databricks auth token --host H` with multiple matching profiles errors with a suggestion (or prompts interactively) - **Profile matching predicates**: `WithHost()` and `WithHostAndAccountID()` in the profile package, using the SDK's canonical host normalization - Account/unified hosts are matched by host + account ID (not host alone) to avoid false ambiguity when profiles share a host but differ by account - Host is canonicalized before `HostType()` classification so scheme-less hosts (e.g. `accounts.cloud.databricks.com`) are correctly identified as account hosts ## New test cases 1. **Positional arg resolved as profile name**: `args: []string{"workspace-a"}`, no `profileName`. Expects success — token returned via profile-based cache key. 2. **Positional arg with dot treated as host when no profile matches**: `args: []string{"workspace-a.cloud.databricks.com"}`. No profile matches, falls through to host path. 3. **Dotted profile name resolved as profile not host**: `args: []string{"default.dev"}`. Profile lookup matches first, no host heuristic needed. 4. **Positional arg not a profile, falls through to host**: `args: []string{"nonexistent"}`, no `profileName`. Falls through to host treatment, gets cache miss error (backward compat). 5. **Scheme-less account host ambiguity detected correctly**: `Host: "accounts.cloud.databricks.com"` (no scheme), `AccountID: "same-account"`. Verifies canonicalization before `HostType()` classification. 6. **Workspace host ambiguity — multiple profiles, non-interactive**: Use `cmdio.MockDiscard(ctx)`. `Host: "https://shared.cloud.databricks.com"`. Expected error contains `"dup1 and dup2 match"` and `"Use --profile"` and config file path. 7. **Account host — same host, different account IDs → no ambiguity**: `Host: "https://accounts.cloud.databricks.com"`, `AccountID: "active"`. Both `expired` and `active` share the host but have different account IDs → only one matches → no ambiguity. Validates the over-triggering fix. 8. **Account host — same host AND same account ID → ambiguity**: Use `cmdio.MockDiscard(ctx)`. `Host: "https://accounts.cloud.databricks.com"`, `AccountID: "same-account"`. Both `acct-dup1` and `acct-dup2` match → ambiguity error. 9. **Profile flag + positional non-host arg still errors**: `profileName: "active"`, `args: []string{"workspace-a"}`. Expected error: `"providing both a profile and host is not supported"`. ## Verification 1. `go test ./cmd/auth/ -run TestToken_loadToken -v` — all 16 test cases pass 2. `go test ./libs/databrickscfg/profile/ -v` — WithHost predicate tests pass 3. `go test ./acceptance -run TestAccept/cmd/auth/token -v` — acceptance test still passes (existing error message preserved) 4. `make checks` — whitespace and formatting pass 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
deco-sdk-tagging bot
added a commit
that referenced
this pull request
Feb 26, 2026
## Release v0.290.0 ### CLI * Add `completion install`, `uninstall`, and `status` subcommands ([#4581](#4581)) * Wire profile name through CLI ToOAuthArgument for profile-based cache keys ([#4562](#4562)) * Add host disambiguation and positional profile support to auth token ([#4574](#4574)) * Update error messages to suggest 'databricks auth login' ([#4587](#4587)) * Resolve --host to matching profile for token cache lookup ([#4591](#4591)) * Improve auth token UX: profile selection and better empty-state handling ([#4584(#4584) ### Bundles * Added support for git_source and git_repository for Apps ([#4538](#4538)) ### Dependency updates * Upgrade TF provider to 1.109.0 ([#4561](#4561)) * Upgrade Go SDK to v0.110.0 ([#4552](#4552)) ### API Changes * Bump databricks-sdk-go from v0.111.0 to v0.112.0.
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.
Changes
Profilefield toAuthArgumentsstruct inlibs/auth/arguments.go.ToOAuthArgument()fromNewBasic*toNewProfile*constructors, passing the profile name so the SDK uses profile-based cache keys when a profile is specified.cmd/auth/token.goandcmd/auth/login.gointoAuthArgumentsbefore callingToOAuthArgument().Why
The SDK already supports profile-based OAuth token cache keys, but the CLI never passes the profile name through to the SDK constructors. This means
auth token --profile Xandauth login --profile Xstill use host-based cache keys, making profile-based caching a no-op. This is a prerequisite for profile-based cache keys to work end-to-end.Tests
libs/auth,cmd/auth)token_test.goin-memory cache with profile-based entriescmd/auth/*)make checkspassesTested manually by creating two profiles that were with the same host.
Results:
Two profiles, same host, different tokens with different expiry times. That's the whole point of this change — before, they'd share one cache entry keyed by https://e2-dogfood.staging.cloud.databricks.com and one login would clobber the other. Now they each get their own entry keyed by profile name.