Pin cfg.Profile to the resolved name in resolveDefaultProfile

[simonfaltum]

Why

databricks auth login --profile DEFAULT --host ... followed by a no-flag databricks auth describe (or any other command that needs the U2M token) fails when secure storage is in use:

Unable to authenticate: A new access token could not be retrieved because the refresh token is invalid.

databricks auth describe --profile DEFAULT works. Running the same flow under DATABRICKS_AUTH_STORAGE=plaintext also works. So the bug is specific to secure storage + the implicit DEFAULT fallback.

Root cause is a cache-key mismatch between login and read:

• cmd/auth/login.go:222 hardcodes profileName = "DEFAULT" when no --profile is given, so the OAuthArgument's cache key is the literal string "DEFAULT". The token lands in the keyring under account "DEFAULT".
• On the read path, cfg.Profile starts empty, resolveDefaultProfile only consults [__settings__].default_profile (so it stays empty), and the SDK's configFileLoader.Configure (config_file.go:103-105) loads [DEFAULT]'s values but deliberately leaves cfg.Profile empty when it falls back (isFallback=true). CLICredentials.Configure then builds an OAuthArgument with profile="", so GetCacheKey() falls back to GetHostCacheKey() and the lookup goes to the host URL, not "DEFAULT". Miss.

plaintext mode masks the same mismatch with DualWritingTokenCache, which mirrors every write under the host key — so reads via host URL still find the token. secure mode does not dual-write, so the bug surfaces.

This is a pre-existing bug independent of toggling secure-storage by default, but doing so turns a corner case into the default experience. The fix here is targeted enough to land standalone.

A defense-in-depth followup in databricks-sdk-go will drop the SDK-side if !isFallback gate so all SDK consumers benefit from the same self-consistency. The CLI fix lands first so secure-storage users are unblocked without waiting on an SDK release cycle.

Changes

• cmd/root/auth.go: resolveDefaultProfile swaps databrickscfg.ResolveDefaultProfile (settings-only) for databrickscfg.GetDefaultProfile, which already does the full 4-step resolution: [__settings__].default_profile → the only profile in the file → [DEFAULT] → empty. The SDK then sees a non-empty cfg.Profile, takes the isFallback=false branch, and the name flows through to CLICredentials.Configure. OAuthArgument's cache key now matches what login wrote.
• cmd/root/bundle.go is intentionally NOT touched: bundles deliberately limit their fallback to [__settings__].default_profile so a hostless bundle does not get silently routed at a [DEFAULT] profile pointing at the wrong workspace. That comment in bundle.go:74-80 stays load-bearing.
• cmd/root/auth_test.go:
  • TestMustWorkspaceClientWithoutConfiguredDefaultFallsBackToDefaultSection now asserts cfg.Profile == "DEFAULT" (was ""). The previous assertion documented the bug; the new one documents the contract.
  • New table-driven TestResolveDefaultProfile covers the full resolution order: preset cfg.Profile, DATABRICKS_CONFIG_PROFILE env, [__settings__].default_profile, single profile, [DEFAULT] section among many, no fallback, missing file.
• NEXT_CHANGELOG.md: one-line entry describing the fix and the mismatch it removes.

Test plan

• task checks clean
• task lint-q clean
• go test ./cmd/root/... ./cmd/auth/... ./libs/databrickscfg/... passes
• go test ./acceptance -run 'TestAccept/cmd/auth' passes
• Manual repro of Pieter's case (auth login --profile DEFAULT --host ... then auth describe with no flag under secure storage) succeeds after this PR; the same flow on main fails.
• Verify bundle resolution is unaffected: a bundle without workspace.host and no --profile still uses [__settings__].default_profile only (no silent DEFAULT routing).

This pull request and its description were written by Isaac.

[pietern]

Why is this not part of ResolveDefaultProfile?

Then the function in auth.go can remain unchanged.

The only thing this does extra is the ini probe.

[simonfaltum]

ResolveDefaultProfile is also called from cmd/root/bundle.go:80, which deliberately only does the settings lookup; see the comment immediately above the call:

Fall back to [settings].default_profile only when the bundle does not pin its own workspace.host. ... a default_profile here could route the user to a profile that points at the wrong workspace, masking config errors.

So folding the [DEFAULT] section probe into ResolveDefaultProfile changes the bundle's deploy resolution: a hostless bundle would now silently fall back to whatever [DEFAULT] points at. That's what the bundle comment was added to prevent.

Two ways to do what you're suggesting:

1. Keep ResolveDefaultProfile as-is and let auth use a separate function (current PR).
2. Promote the new behavior into ResolveDefaultProfile and switch bundle to GetConfiguredDefaultProfile (or a new narrow wrapper) directly.

Happy with either. If you prefer (2), I can rename GetAuthDefaultProfile -> ResolveDefaultProfile, drop the current ResolveDefaultProfile, and update bundle.go. Let me know.

[pietern]

2 sounds cleanest.

Btw, there are other callers of ResolveDefaultProfile that need to benefit from this change.

For ex, otherwise auth token would not resolve DEFAULT either.

[simonfaltum]

auth token afaik never did, you always needed to be specific on what you wanted - at least that is the behavior today

[simonfaltum]

Done in c11c17c. Extended ResolveDefaultProfile to also probe [DEFAULT], dropped GetAuthDefaultProfile, reverted resolveDefaultProfile in cmd/root/auth.go to the original one-liner. Every existing caller (cmd/api, cmd/auth/token, cmd/auth/describe via cmd/root/auth, cmd/root/bundle) now benefits — same scope of fallback that already accepts [settings].default_profile. Net -61 lines.