Skip to content

air: send submit's config validation over the CLI's existing connection - #7210

Open
stevenchen-db wants to merge 2 commits into
mainfrom
schen/air-validate-shared-connection
Open

stevenchen-db wants to merge 2 commits into
mainfrom
schen/air-validate-shared-connection

Conversation

@stevenchen-db

Copy link
Copy Markdown
Contributor

Changes

air run sends its pre-upload config:validate request through an SDK client, so it reuses the workspace connection the CLI's other calls already opened. The request is built the same way as before and still gets exactly one attempt.

Why

The validation call used its own clone of http.DefaultTransport, so every air run opened a second TCP and TLS connection to the workspace. That costs about one extra connection setup plus two TLS round trips, which is small in-region and large from a laptop.

Measured on a test workspace, SCIM Me followed by the validation call, 15 fresh processes per build:

main p50 this PR p50
In-region 82ms 67ms
+50ms network round trip (emulated) 328ms 169ms

One behavior change: the SDK reports a failed response-body read without the HTTP status. A caller-error response (e.g. 401) whose body stalls mid-read now counts as validation being unavailable, so the submission continues instead of stopping. The server validates the run again when it starts.

Tests

  • New TestPreflightValidationReusesSDKConnection: an SDK call followed by validation opens one connection (fails with 2 on main).
  • TestPreflightValidationBodyReadFailureOnCallerErrorBlocks is now ...FailsOpen, for the behavior change above. All other validation tests pass unchanged (single attempt, fail-open on timeouts, transport errors and malformed responses, blocking on caller errors and visitor errors, cancellation, OAuth refresh deadline).
  • go test ./cmd/air/ and go test ./acceptance -run TestAccept/air pass; ./task fmt, ./task checks and ./task lint are clean.

This pull request and its description were written by Isaac.

The submit-path config:validate request used its own clone of
http.DefaultTransport, so every `air run` opened a second TCP and TLS
connection to the workspace. Send it through an SDK client instead, so it
reuses the connection the CLI's other calls already opened. The request is
still built the same way and gets one attempt.

The SDK reports a failed response-body read without the HTTP status, so a
caller-error response whose body stalls now counts as validation being
unavailable and the submission continues; the server validates the run again
when it starts.

Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
@github-actions github-actions Bot added the AIR Databricks AI Runtime CLI label Oct 28, 2026
@eng-dev-ecosystem-bot

Copy link
Copy Markdown
Collaborator

Integration test report

Commit: 0b62bdf

Run: 40614056185

Env ✅​pass 🙈​skip Time
✅​ aws linux-2core-8gb 281 15 5:38
✅​ aws-windows-latest-4core-16gb 283 13 3:30
✅​ azure linux-2core-8gb 280 15 5:29
✅​ azure-windows-latest-4core-16gb 282 13 3:20
✅​ gcp linux-2core-8gb 281 15 5:58
✅​ gcp-windows-latest-4core-16gb 283 13 3:25
Top 6 slowest tests (at least 2 minutes):
duration env testname
4:02 gcp linux-2core-8gb TestAccept
3:47 aws linux-2core-8gb TestAccept
3:47 azure linux-2core-8gb TestAccept
3:23 aws-windows-latest-4core-16gb TestAccept
3:19 gcp-windows-latest-4core-16gb TestAccept
3:14 azure-windows-latest-4core-16gb TestAccept

@maggiewang-db maggiewang-db left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you do an E2E test and make sure databricks air run works?

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

AIR Databricks AI Runtime CLI

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants