CXH-2165: fix Databricks account host for Azure and GCP tenants

[al-conductorone]

Azure and GCP Databricks tenants now connect and sync automatically instead of failing, by calculating the correct account address from the workspace address rather than always defaulting to the AWS one.

[linear-code]

CXH-2165

[github-actions]

Connector PR Review: CXH-2165: fix Databricks account host for Azure and GCP tenants

Blocking Issues: 0 | Suggestions: 1 | Threads Resolved: 0
Criteria: Criteria status: loaded .claude/skills/ci-review.md from trusted base 5aba277cd2a6.
Review mode: full
View review run

Review Summary

The full PR diff was scanned for security and correctness. This PR corrects the GCP account host constant (gcp.databricks.net -> gcp.databricks.com) and removes the AWS-specific default on the account-hostname field so the per-cloud calculation in getAccountHostname actually runs for Azure/GCP tenants. The gcpHost fix and the calculation logic are correct and covered by the new connector_test.go. One non-blocking edge case is noted below regarding AWS workspace-specific hostnames.

Security Issues

None found.

Correctness Issues

None found.

Suggestions

• pkg/databricks/client.go:48-54 - GetAccountHostname normalizes Azure/GCP via HasSuffix to a fixed base domain, but the AWS fallback just prepends accounts. to the raw hostname. Now that the field default is removed, an AWS install with a workspace-specific hostname such as dbc-xxxx.cloud.databricks.com and no explicit account-hostname will compute accounts.dbc-xxxx.cloud.databricks.com instead of accounts.cloud.databricks.com. Previously the field default masked this. Low confidence - depends on whether real deployments set non-base AWS hostnames.

Prompt for AI agents

Verify each finding against the current code and only fix it if needed.

## Suggestions

In pkg/databricks/client.go:
- Around line 48-54: GetAccountHostname handles Azure and GCP by matching the
  hostname suffix and returning accounts dot base-domain, but the AWS path simply
  returns accounts dot plus the raw hostname. Since the account-hostname field
  default was removed, an AWS workspace whose hostname is a workspace-specific
  subdomain such as dbc-1234.cloud.databricks.com and that does not override
  account-hostname will now produce accounts.dbc-1234.cloud.databricks.com instead
  of the correct accounts.cloud.databricks.com. If AWS deployments can supply
  workspace-specific hostnames, normalize the AWS branch the same way (strip the
  workspace subdomain and return accounts.cloud.databricks.com), or document that
  hostname must be the base account domain for AWS.

[github-actions]

No blocking issues found.

[github-actions]

Connector PR Review: CXH-2165: fix Databricks account host for Azure and GCP tenants

Blocking Issues: 0 | Suggestions: 1 | Threads Resolved: 0
Criteria: Criteria status: loaded .claude/skills/ci-review.md from trusted base 5aba277cd2a6.
Review mode: full
View review run

Review Summary

The full PR diff was scanned for security and correctness. This PR removes the hardcoded accounts.cloud.databricks.com default so the account API host is derived from the workspace hostname, fixes the GCP suffix (gcp.databricks.net to gcp.databricks.com), and migrates deprecated trait-level profile/status setters (WithGroupProfile/WithRoleProfile/WithUserProfile/WithStatus) to the resource-level equivalents (WithResourceProfile/WithResourceStatus/GetProfile). I verified against the vendored baton-sdk v0.20.5 that all new APIs exist and that GetProfile falls back to trait-level profiles, so the migration is backward-compatible with previously synced data. A new regression test covers the Azure/GCP/AWS hostname calculation. No security issues found and no blocking correctness issues.

Security Issues

None found.

Correctness Issues

None found.

Suggestions

• pkg/databricks/client.go:48-54 — GetAccountHostname normalizes Azure/GCP via HasSuffix to a fixed base domain, but the AWS fallback prepends accounts. to the raw hostname. With the field default now removed, an AWS install using a workspace-specific hostname (e.g. dbc-xxxx.cloud.databricks.com) and no explicit --account-hostname will compute accounts.dbc-xxxx.cloud.databricks.com instead of accounts.cloud.databricks.com. Previously the default masked this. Medium confidence — depends on whether real AWS deployments put workspace-specific hostnames in the hostname field.

Prompt for AI agents

Verify each finding against the current code and only fix it if needed.

## Suggestions

In pkg/databricks/client.go:
- Around line 48-54: GetAccountHostname handles Azure and GCP by matching the
  hostname suffix and returning a fixed accounts.<base> host, but the AWS path
  falls through to "accounts." + hostname, which is only correct when the
  hostname is exactly the base cloud.databricks.com. For a workspace-specific
  AWS hostname like dbc-xxxx.cloud.databricks.com this produces
  accounts.dbc-xxxx.cloud.databricks.com, which is wrong. Now that the
  account-hostname config default was removed, AWS installs that relied on the
  default and use a workspace-specific hostname will break. Fix by normalizing the
  AWS case the same way as Azure/GCP: detect the cloud.databricks.com suffix and
  return accounts.cloud.databricks.com, rather than prepending accounts. to the
  full workspace hostname.

[github-actions]

No blocking issues found.