Pass --force-refresh to CLI auth token command#752
Pass --force-refresh to CLI auth token command#752mihaimitrea-db wants to merge 2 commits intomainfrom
Conversation
628f509 to
09cdbc4
Compare
Range-diff: stack/cli-force-refresh (628f509 -> 09cdbc4)
Reproduce locally: |
09cdbc4 to
f88c52a
Compare
Range-diff: stack/cli-force-refresh (09cdbc4 -> f88c52a)
Reproduce locally: |
f88c52a to
25a3779
Compare
Range-diff: stack/cli-force-refresh (f88c52a -> 25a3779)
Reproduce locally: |
25a3779 to
694521d
Compare
Range-diff: stack/cli-force-refresh (25a3779 -> 694521d)
Reproduce locally: |
694521d to
0f6baf6
Compare
Range-diff: stack/cli-force-refresh (694521d -> 0f6baf6)
Reproduce locally: |
0f6baf6 to
0ef99dc
Compare
0ef99dc to
0dd48d1
Compare
Range-diff: stack/cli-force-refresh (0ef99dc -> 0dd48d1)
Reproduce locally: |
0dd48d1 to
a69ceff
Compare
a69ceff to
68844a4
Compare
`--profile` on `databricks auth token` is a global Cobra flag, so old CLIs (< v0.207.1) silently accept it and fail later with `cannot fetch credentials` instead of `unknown flag: --profile`. The previous error-based fallback never matched, leaving the `--host` fallback as dead code. This commit replaces the runtime fallback chain with version-based capability detection: * `CliVersion` carries a (major, minor, patch) triple plus an `UNKNOWN` sentinel and a default-dev-build (0,0,0) check. * `DatabricksCliCredentialsProvider` runs `databricks version --output json` once per CLI path (cached on success only, with a 5s timeout) and gates `--profile` on >= v0.207.1; everything else falls back to `--host` with a precise warning. * `CliTokenSource` is simplified to a single `cmd`; the `fallbackCmd` parameter and the runtime "unknown flag" retry loop are removed. Mirrors the equivalent refactors in the Go and Python SDKs: * databricks/databricks-sdk-go#1605 * databricks/databricks-sdk-py#1377 Co-authored-by: Isaac
The SDK manages its own token caching via `CachedTokenSource`. When the SDK shells out to `databricks auth token`, the CLI may return a token from *its* own cache that is about to expire (or has already expired from the SDK's perspective), producing unnecessary refresh failures and retry loops. The CLI added `--force-refresh` in v0.296.0 (databricks/cli#4767) to let callers bypass its cache. With the version-detection infrastructure from the parent PR already in place, opting in is a one-constant, one-branch change: * Introduce `CLI_VERSION_FOR_FORCE_REFRESH = v0.296.0`. * Split `buildCliCommand` into the existing profile/host decision (now `buildCoreCliCommand`) and a thin wrapper that appends `--force-refresh` when supported and otherwise logs a precise warning. Future capability-gated flags slot into the same wrapper. Mirrors: * databricks/databricks-sdk-go#1628 * databricks/databricks-sdk-py#1378 Co-authored-by: Isaac
68844a4 to
5ee2187
Compare
|
If integration tests don't run automatically, an authorized user can run them manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
🥞 Stacked PR
Use this link to review incremental changes.
Summary
Append
--force-refreshto thedatabricks auth tokencommand when the installed CLI is >= v0.296.0, so the CLI bypasses its internal token cache and hands the SDK a freshly minted token every time.Mirrors databricks/databricks-sdk-go#1628 and databricks/databricks-sdk-py#1378. Requires the version-detection infrastructure from the parent PR #751.
Why
The SDK already manages its own token caching via
CachedTokenSource. When the SDK decides it needs a new token and shells out todatabricks auth token, the CLI may return a token from its own cache that is about to expire (or that has already expired from the SDK's perspective). That produces unnecessary refresh failures and retry loops on top of a value that the SDK was confident was fresh.The CLI added
--force-refreshin databricks/cli#4767 (motivated by databricks/cli#4564) specifically to let callers bypass the CLI's cache. With the version-detection infrastructure from the parent PR already in place, opting in is a one-constant, one-branch change.What changed
Interface changes
None.
CliTokenSourceis not part of the public API surface.Behavioral changes
databricks auth tokeninvocations now end with--force-refreshwhenever the detected CLI is >= v0.296.0. Callers on older CLIs see no change.WARNINGis logged:"Databricks CLI <ver> does not support --force-refresh (requires >= v0.296.0). The CLI's token cache may provide stale tokens."AzureCliCredentialsProvideris unaffected — it does not pass throughDatabricksCliCredentialsProviderand does not opt into version-gated flag selection.Internal changes
DatabricksCliCredentialsProvider.CLI_VERSION_FOR_FORCE_REFRESH = new DatabricksCliVersion(0, 296, 0).buildCliCommandis split into two helpers, matching the shape the Go and Python SDKs settled on after the same PR there:buildCoreCliCommand(cliPath, config, version)— holds the existing profile-vs-host decision (moved out ofbuildCliCommand).buildCliCommand(cliPath, config, version)— now a thin wrapper that callsbuildCoreCliCommand, appends--force-refreshwhenversion.atLeast(CLI_VERSION_FOR_FORCE_REFRESH), and otherwise logs the unsupported-versionWARNING.Future version-gated flags slot into the same pattern: add a
CLI_VERSION_FOR_<flag>constant and anif version.atLeast(...)block inbuildCliCommand.How is this tested?
Additional
testBuildCliCommandparameterized cases inDatabricksCliCredentialsProviderTestcover the full matrix:--host+ v0.296.0 → appends--force-refresh.--host+ v0.296.0 → appends--force-refresh.--profile+ v0.296.0 →--profile+--force-refresh.--profile+ v0.207.1 →--profileonly (too old for--force-refresh).--host+ v0.295.0 →--hostonly (too old for--force-refresh).--hostonly, no--force-refresh.--hostonly, no--force-refresh.All parent-PR tests continue to pass unchanged.