auth: bound per-profile validation with a 10s timeout#5928
Merged
Conversation
`databricks auth profiles` validates each profile with a live API call (Workspaces.List or CurrentUser.Me). The SDK retries transient network failures — connection refused, connect/TLS timeout, retriable 5xx — for its default RetryTimeoutSeconds (~5 minutes), so a single unreachable workspace stalls the entire listing. (Hosts that fail DNS are not retriable and already fail fast; those never stalled.) Bound each validation with a 10s context timeout, and set the same value on HTTPTimeoutSeconds/RetryTimeoutSeconds so the host-metadata fetch in EnsureResolved is bounded too — it runs on context.Background internally, so the context.WithTimeout on the validation call cannot reach it. Adds a regression test that points a profile at a server which hangs until the client cancels and asserts Load returns bounded rather than retrying to the SDK default. profileValidationTimeout is a var so the test can shrink it. Co-authored-by: Isaac
janniklasrose
temporarily deployed
to
test-trigger-is
July 15, 2026 08:08 — with
GitHub Actions
Inactive
janniklasrose
temporarily deployed
to
test-trigger-is
July 15, 2026 08:08 — with
GitHub Actions
Inactive
janniklasrose
temporarily deployed
to
test-trigger-is
July 15, 2026 11:25 — with
GitHub Actions
Inactive
janniklasrose
temporarily deployed
to
test-trigger-is
July 15, 2026 11:25 — with
GitHub Actions
Inactive
andrewnester
approved these changes
Jul 21, 2026
janniklasrose
enabled auto-merge
July 21, 2026 10:21
Collaborator
Integration test reportCommit: d202457
10 interesting tests: 4 RECOVERED, 4 SKIP, 2 flaky
|
pietern
reviewed
Jul 21, 2026
| @@ -0,0 +1 @@ | |||
| * `databricks auth profiles` no longer stalls on an unreachable workspace. Each profile is now validated with a 10s timeout (also applied to the host-metadata fetch in `EnsureResolved`), so a host the SDK would otherwise retry — connection refused, connect/TLS timeout, or a retriable 5xx — can't block the whole listing for the SDK's default ~5-minute retry budget. | |||
Contributor
There was a problem hiding this comment.
Nit: outdated changelog with 5s change.
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
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.
Changes
Bound each per-profile validation in
databricks auth profileswith a 10s timeout.auth profilesvalidates every profile with a live API call (Workspaces.Listfor account configs,CurrentUser.Mefor workspace configs). The SDK retries transient network failures — connection refused, connect/TLS timeout, retriable 5xx — for its defaultRetryTimeoutSeconds(~5 minutes). So a single unreachable-but-retriable workspace stalls the entire listing for minutes.context.WithTimeout(ctx, 10s).cfg.HTTPTimeoutSeconds/cfg.RetryTimeoutSeconds, because the host-metadata fetch inEnsureResolvedruns oncontext.Backgroundinternally and so can't be reached by the validation call's context — without these it would still retry for ~5 minutes.Hosts that fail DNS (e.g. a typo'd or reserved hostname) are not retriable and already fail fast; this only bounds the retriable cases.
Why
Users with a decommissioned, firewalled, or otherwise unresponsive workspace in
~/.databrickscfgseeauth profileshang for minutes on that one entry, blocking the whole list. Bounding each validation keeps the command responsive.Tests
TestProfileLoadTimesOutOnUnresponsiveHost(cmd/auth/profiles_test.go) — points a profile at anhttptestserver that hangs every request until the client cancels, and assertsLoadreturns bounded rather than retrying to the SDK default. The handler waits on the request context soserver.Closedoesn't block on a leaked connection.profileValidationTimeoutis avarso the test shrinks it (kept ≥1s, sinceLoadderives the SDK's integer-second budgets from it and a sub-second value floors to 0 = "use default").cmd/authpackage and./task lint-qpass.This pull request and its description were written by Isaac, an AI coding agent.