auth: honor --host on auth describe and prefer default profile when host is ambiguous#5343
Merged
Merged
Conversation
…rofile `databricks auth describe --host X` silently ignored the flag: the value was bound to the parent command's `authArguments.Host` but never read by the describe flow, so the SDK fell back to [__settings__].default_profile (silently describing a different host) or the "default auth: cannot configure default credentials" error even when a host-matching profile existed. The display still labelled the value "(from --host flag)", making the mismatch hard to spot. - describe.go: when --host is set without --profile, resolve the host to a profile name (via the existing `resolveHostToProfile`) and set --profile so MustAnyClient uses it. DATABRICKS_CONFIG_PROFILE is left alone — it's an explicit user signal. - resolve.go: when multiple profiles match a host, prefer the [__settings__].default_profile if it's one of them, before falling back to the picker or ambiguity error. Same helper is used by `auth logout`, which gets the same UX improvement. Co-authored-by: Isaac
simonfaltum
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
simonfaltum
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
Collaborator
|
Commit: 9fe91b9 |
GPT review caught two test gaps: - TestResolveHostToProfileMatchesMultipleProfiles relied on whatever default_profile happened to be in the caller's real .databrickscfg. After the new prefer-default branch, a local default could inadvertently resolve the call instead of returning the expected ambiguity error. Point DATABRICKS_CONFIG_FILE at an empty temp file for the test. - The auth describe --host wiring (resolveProfileFromHostFlag) had no direct test; the only coverage was indirect through resolveHostToProfile. Add focused subtests for the no-op, --profile precedence, single-match, no-match, and DATABRICKS_CONFIG_PROFILE bail-out cases. Co-authored-by: Isaac
simonfaltum
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
simonfaltum
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
mihaimitrea-db
approved these changes
May 27, 2026
Comment on lines
+78
to
+88
| // Prefer the configured default profile when it's one of the host | ||
| // matches, so commands that pass --host don't trip the picker for | ||
| // users who already picked a default. | ||
| if defaultProfile, _ := databrickscfg.GetDefaultProfile(ctx, env.Get(ctx, "DATABRICKS_CONFIG_FILE")); defaultProfile != "" { | ||
| for _, p := range hostProfiles { | ||
| if p.Name == defaultProfile { | ||
| log.Debugf(ctx, "multiple profiles match host %q; using default profile %q", host, defaultProfile) | ||
| return p.Name, nil | ||
| } | ||
| } | ||
| } |
Contributor
There was a problem hiding this comment.
This behaviour would also propagate to auth logout but I'd say that's fine.
Collaborator
|
Commit: c19a115 |
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
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
`databricks auth describe --host X` silently ignored the flag. The value was bound to the parent `auth` command's `authArguments.Host` but never read by the describe flow, so the SDK fell back to `[settings].default_profile` (silently describing a different host than the one named) or the "default auth: cannot configure default credentials" error even when a host-matching profile existed. The display still labelled the value `(from --host flag)`, making the mismatch hard to spot. Reported in a bug bash.
Reproduced against `db-deco-test.databricks.com` (which has two matching profiles in my .databrickscfg):
```
$ databricks auth describe --host https://db-deco-test.databricks.com
Host: https://dogfood.staging.databricks.com ← actually dogfood, not db-deco-test
✓ host: https://dogfood.staging.databricks.com (from --host flag) ← misleading label
✓ profile: dogfood
```
Changes
After the fix, against the same host:
```
$ databricks auth describe --host https://db-deco-test.databricks.com
Error: multiple profiles found matching host "https://db-deco-test.databricks.com\":
spog-deco-aws, db-deco-test-chrisst. Please specify the profile name directly
```
And with `default_profile = spog-deco-aws` in `[settings]`, the same command auto-selects `spog-deco-aws` without prompting.
Test plan