Uh oh!
There was an error while loading. Please reload this page.
Resolve --host to matching profile for token cache lookup - #4591
Merged
Conversation
When `auth token --host` is provided without `--profile`, and exactly one profile in .databrickscfg matches that host, use the profile name as the cache key instead of the host URL. This ensures tokens stored under the profile key are found regardless of whether --host or --profile was used.
simonfaltumtemporarily deployed
to
test-trigger-is
February 24, 2026 18:05 — with 
GitHub Actions
Inactive
Collaborator
Commit: 5052555
15 interesting tests: 7 KNOWN, 7 SKIP, 1 RECOVERED
Top 20 slowest tests (at least 2 minutes):
|
simonfaltum
marked this pull request as ready for review
February 24, 2026 18:27
simonfaltum
requested review from
andrewnester, anton-107, denik, pietern and shreyas-goenka
as code ownersFebruary 24, 2026 18:27
renaudhartert-db
approved these changes
Feb 24, 2026
Uh oh!
There was an error while loading. Please reload this page.
deco-sdk-taggingBot
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.
denik pushed a commit
that referenced
this pull request
May 20, 2026
## Why When you run `databricks auth token --host <url>`, the CLI looks up the token using the host URL as the cache key. But if you logged in with `--profile`, the token was stored under the profile name, not the host URL. So `--host` can't find it — even though the token exists and the profile points to exactly that host. This is the flip side of the bug fixed in databricks/databricks-sdk-go#1497: that PR made `--profile` fall back to the host key. This PR makes `--host` resolve to the profile key. Together, both directions work: `--profile` finds host-keyed tokens, and `--host` finds profile-keyed tokens. ## Changes Two-line change in `loadToken` (`cmd/auth/token.go`). The CLI already loads all profiles matching a given host and errors when there are multiple matches (the ambiguity check). This PR adds an `else if` branch: when exactly one profile matches, use that profile's name as the cache key instead of the raw host URL. ```go if len(matchingProfiles) > 1 { // existing: ambiguity error } else if len(matchingProfiles) == 1 { args.profileName = matchingProfiles[0].Name } ``` The matching is already host-type-aware from the existing code: - Workspace hosts match by host URL - Account/unified hosts match by host URL + account ID No new matching logic was added. **Side effect**: error messages now suggest `--profile <name>` instead of `--host <url>` when the host resolves to a profile. This is better UX — if we know the profile, we should suggest it. ## Test plan Three new test cases added to `TestToken_loadToken`: 1. **Host with one matching profile resolves to profile key** — token exists only under the profile key (not the host URL). `--host` finds it by resolving to the profile first. 2. **Host with no matching profile uses host key** — no profile in `.databrickscfg` matches the host. Falls back to looking up by host URL directly. Unchanged behavior. 3. **Host with one matching profile, host-key-only token (migration)** — profile exists in `.databrickscfg` but the token was stored under the host URL only (legacy). CLI resolves `--host` to the profile name, then the SDK's read-fallback (from [#1497](databricks/databricks-sdk-go#1497)) finds the token under the host key. All existing tests continue to pass. One existing test's expected error message changed from `--host ... --account-id ...` to `--profile expired` because the host now resolves to the `expired` profile. ### Manual testing I tested this manually with my local `.databrickscfg`: ``` $ databricks auth token --host https://adb-2548836972759138.18.azuredatabricks.net/ ``` This host matches my `logfood` profile. Before this change, it would look up by host URL. After this change, it resolves to `logfood` and looks up by profile key. The token is returned in both cases (because `dualWrite` currently populates both keys), but the cache key used is now the profile name.
denik pushed a commit
that referenced
this pull request
May 20, 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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Why
When you run
databricks auth token --host <url>, the CLI looks up the token using the host URL as the cache key. But if you logged in with--profile, the token was stored under the profile name, not the host URL. So--hostcan't find it — even though the token exists and the profile points to exactly that host.This is the flip side of the bug fixed in databricks/databricks-sdk-go#1497: that PR made
--profilefall back to the host key. This PR makes--hostresolve to the profile key.Together, both directions work:
--profilefinds host-keyed tokens, and--hostfinds profile-keyed tokens.Changes
Two-line change in
loadToken(cmd/auth/token.go).The CLI already loads all profiles matching a given host and errors when there are multiple matches (the ambiguity check). This PR adds an
else ifbranch: when exactly one profile matches, use that profile's name as the cache key instead of the raw host URL.The matching is already host-type-aware from the existing code:
No new matching logic was added.
Side effect: error messages now suggest
--profile <name>instead of--host <url>when the host resolves to a profile. This is better UX — if we know the profile, we should suggest it.Test plan
Three new test cases added to
TestToken_loadToken:--hostfinds it by resolving to the profile first..databrickscfgmatches the host. Falls back to looking up by host URL directly. Unchanged behavior..databrickscfgbut the token was stored under the host URL only (legacy). CLI resolves--hostto the profile name, then the SDK's read-fallback (from #1497) finds the token under the host key.All existing tests continue to pass. One existing test's expected error message changed from
--host ... --account-id ...to--profile expiredbecause the host now resolves to theexpiredprofile.Manual testing
I tested this manually with my local
.databrickscfg:This host matches my
logfoodprofile. Before this change, it would look up by host URL. After this change, it resolves tologfoodand looks up by profile key. The token is returned in both cases (becausedualWritecurrently populates both keys), but the cache key used is now the profile name.