Implement CLICredentials to read tokens from the local cache#4570
Merged
renaudhartert-db merged 10 commits intomainfrom Feb 24, 2026
Merged
Implement CLICredentials to read tokens from the local cache#4570renaudhartert-db merged 10 commits intomainfrom
renaudhartert-db merged 10 commits intomainfrom
Conversation
The SDK's `u2m` credentials strategy (auth type "databricks-cli") shells out to `databricks auth token` as a subprocess to obtain OAuth tokens. When the CLI itself is the process, this creates a circular dependency: the CLI spawns a child copy of itself just to read the token cache. Implement `CLICredentials.Configure()` to read OAuth tokens directly from the local token cache via `u2m.PersistentAuth`, bypassing the subprocess entirely. The `init()` function registers this strategy in the CLI's custom credentials chain, which runs on every CLI invocation regardless of the command being executed. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
renaudhartert-db
requested review from
andrewnester,
anton-107,
denik,
pietern and
shreyas-goenka
as code owners
renaudhartert-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
Collaborator
|
Commit: 3f35235
15 interesting tests: 8 RECOVERED, 7 SKIP
Top 37 slowest tests (at least 2 minutes):
|
renaudhartert-db
changed the title
renaudhartert-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
renaudhartert-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
renaudhartert-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
The SDK's credentialsChain has an empty name when no strategy succeeds, producing " auth: cannot configure..." instead of "default auth: ...". Wrap the chain like the SDK's DefaultCredentials to provide the fallback. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
renaudhartert-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
renaudhartert-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
renaudhartert-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
simonfaltum
approved these changes
Feb 24, 2026
Member
simonfaltum
left a comment
simonfaltum
left a comment
There was a problem hiding this comment.
Check my comments, I think the one with cfg.Profile might be a bit important (but if so easy to fix).
Its pretty cool with the init() approach to just register it automatically.
Other than that, it looks good. Approving to unblock
renaudhartert-db
removed this pull request from the merge queue due to a manual request
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
renaudhartert-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
renaudhartert-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
Collaborator
|
Commit: 4684f06
36 interesting tests: 14 RECOVERED, 10 KNOWN, 8 flaky, 3 FAIL, 1 SKIP
Top 50 slowest tests (at least 2 minutes):
|
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.
Summary
Introduces a CLI-owned credentials chain and implements
CLICredentials, a credentials strategy that reads OAuth tokens directly from the local token cache viau2m.PersistentAuth, instead of shelling out todatabricks auth tokenas a subprocess.Why
The SDK authenticates by iterating through an ordered list of credential strategies. One of these —
u2mCredentials(auth type"databricks-cli") — works by spawningdatabricks auth token --host <HOST>as a child process. When the CLI itself is the running process, this is a circular dependency: the CLI shells out to a copy of itself just to read a cached token.This PR does two things to address this:
Introduces a CLI-owned credentials chain. An
init()function inlibs/auth/credentials.gosetsconfig.DefaultCredentialStrategyProviderto a custom chain that the CLI controls. This runs on every CLI invocation — regardless of the command — becauselibs/authis transitively imported by the rest of the CLI. Owning the chain guarantees the CLI remains stable despite the evolution of the SDK, and allows customizing individual strategies.Implements
CLICredentialsas the replacement for the SDK'su2mCredentialsin that chain. Instead of shelling out, it reads the token cache in-process viau2m.PersistentAuth, eliminating the subprocess round-trip.Out of scope: the token retrieval logic is now duplicated between
CLICredentialsand thedatabricks auth tokencommand (cmd/auth/token.go). Sharing this via a common abstraction is not the goal of this PR and will be done as a follow-up.What changed
Interface changes
CLICredentials.PersistentAuthOptions []u2m.PersistentAuthOption— new field that allows injecting test dependencies (token cache, endpoint supplier, HTTP client) into the underlyingu2m.PersistentAuth.Behavioral changes
Commands that previously fell through to the SDK's subprocess-based
u2mCredentialsstrategy will now authenticate in-process viaCLICredentials. The authentication result is identical — same token cache, same refresh logic — but without spawning a child process.Internal changes
init()inlibs/auth/credentials.go— registers a CLI-owned credentials chain viaconfig.DefaultCredentialStrategyProvider, replacing the SDK's default chain. The chain preserves the same strategy order as the SDK, withCLICredentialssubstituted for the SDK'su2mCredentials.CLICredentials.Configure()— converts the SDKconfig.ConfigtoAuthArguments, creates au2m.PersistentAuthto access the token cache (with token refresh), wraps it in aCachedTokenSourcewith async refresh controlled bycfg.DisableOAuthRefreshToken, and returns anOAuthCredentialsProvider.authArgumentsFromConfig()— new helper that bridgesconfig.Configfields (Host,AccountID,WorkspaceID,Experimental_IsUnifiedHost) to the CLI'sAuthArgumentstype.databricks-sdk-goupdated tov0.110.1-0.20260221140112-be1d4d821dd1which exposes theNewCachedTokenSource,WithAsyncRefresh, andNewOAuthCredentialsProviderFromTokenSourceAPIs needed by this implementation.How is this tested?
Unit tests in
libs/auth/credentials_test.go:TestCLICredentialsName— assertsName()returns"databricks-cli".TestCLICredentialsConfigure— table-driven tests with injected token cache and mock endpoint supplier covering: empty host (error), workspace host with valid token, account host with valid token, no cached token, expired token with successful refresh, expired token with failed refresh.Verified with a local build that the
databricks-cliflow properly goes through the new credentials strategy and is able to make requests as expected.