You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
|`oauthClientId` (U2M) | ✅ |❌|**Kernel-side gap.** Kernel U2M hardcodes `client_id` and **rejects**a custom `oauthClientId`; Thrift honors it. |
62
-
|`oauthClientId` + no secret | ✅ (U2M) | ❌ |**Divergence.** Thriftroutes to U2Mwith that id; kernel keys the flow off `oauthClientSecret` presence and throws an M2M "secret required" error. |
60
+
|`oauthScopes`|❌| ✅ |**Thrift ignores `oauthScopes`** — `createAuthProvider` never threads it into `DatabricksOAuth`, so `authenticate()` always falls back to `defaultOAuthScopes` (`['sql','offline_access']`). Only the kernel honors a custom `oauthScopes`; its defaults happen to match Thrift's fallback (U2M = `['sql','offline_access']`, M2M = `['all-apis']`).|
61
+
|`oauthClientId` (U2M) | ✅ |✅|The kernel adapter (`buildKernelConnectionOptions`) forwards a custom `oauthClientId` verbatim on the U2M arm; when it is absent the napi binding applies its own default `client_id`. Whether the native binding then honors or rejects a custom id is not observable from this repo — the TypeScript layer neither hardcodes an id nor rejects one.|
62
+
|`oauthClientId` + no secret | ✅ (U2M) |✅ (U2M) |**Parity.**The kernel keys flow selection off `oauthClientSecret` presence exactly like Thrift, so `oauthClientId` + no secret routes to **U2M** (with the id forwarded) — it does **not** throw an M2M "secret required" error. |
63
63
|`azureTenantId` / `useDatabricksOAuthInAzure`| ✅ | ❌ |**Thrift-only.** Kernel rejects Azure-direct (Entra) OAuth; workspace-OIDC discovery covers Azure workspaces without it. |
64
64
|`persistence` (custom OAuth token store) | ✅ | ❌ |**Thrift-only.** Kernel throws; it auto-persists U2M tokens to `~/.config/databricks-sql-kernel/oauth/` and does not cache M2M. |
65
65
|`authType: 'custom'` (`provider`) | ✅ | ❌ |**Thrift-only.** Kernel supports only `access-token` and `databricks-oauth`. |
|`enableMetricViewMetadata`| ✅ |❌|**Thrift-only in the connector.**Thrift auto-injects `spark.sql.thriftserver.metadata.metricview.enabled=true`(`ThriftBackend.ts`); `KernelBackend`does **not**auto-inject it. The kernel core _can_ accept the raw conf key via `session_conf`, so a caller could pass it manually in `OpenSessionRequest.configuration`. |
108
+
|`enableMetricViewMetadata`| ✅ |⚠️|**Auto-injected for both backends**in `DBSQLClient.openSession`, which sets `spark.sql.thriftserver.metadata.metricview.enabled=true`on `request.configuration` before dispatch. `KernelBackend`folds that into `sessionOptions.sessionConf`, so the conf **does**reach the kernel session config. (`ThriftBackend.ts` performs a second, redundant injection on the Thrift path.) The kernel-side gap is that the key is a non-allowlisted session conf, so it is likely dropped by the kernel's case-insensitive allowlist (see "Session defaults") — not that it is never injected. |
109
109
110
110
## Session defaults (`openSession(request)`)
111
111
@@ -147,14 +147,15 @@ regardless of `useKernel`.
147
147
148
148
### Supported on Thrift, missing / ignored on Kernel
149
149
150
-
1.`enableMetricViewMetadata` — no auto-injection on the kernel path.
150
+
1.`enableMetricViewMetadata` — auto-injected for both backends in
151
+
`DBSQLClient.openSession`, but the conf key is likely dropped by the
152
+
kernel's session-conf allowlist, so it has no effect on the kernel path.
0 commit comments