Summary

Automated fix for #909 — [coverage] Conformance findings: AUTH-013.

Fixed get_python_sql_connector_auth_provider in src/databricks/sql/auth/auth.py to honour a caller-supplied U2M OAuth bundle: it now forwards the caller's oauth_scopes verbatim (instead of hardcoding PYSQL_OAUTH_SCOPES) and, when a foreign oauth_client_id is supplied without a redirect port, falls through to the app-neutral base default [8030] rather than pinning the driver's own app-specific range (8020–8024). This is an offline-only, client-side computed artifact (resolved redirect port/scopes at provider construction) anchored in the AUTH-013 shared spec + reference PR databricks-sql-kernel#247; the interactive U2M login is never completed so the behavior is not end-to-end observable, making the unit test the correct verification. Both red→green tests and the full auth unit suite (15 passed) are green.

Root cause & plan

Root cause: In get_python_sql_connector_auth_provider (src/databricks/sql/auth/auth.py, ~lines 115–134), a caller-supplied U2M OAuth bundle is not honored when a custom oauth_client_id is given: (A) oauth_scopes is hardcoded to PYSQL_OAUTH_SCOPES and the caller's oauth_scopes kwarg is never read, so custom scopes like ["all-apis"] are silently replaced by the driver default sql offline_access; (B) the redirect port only honors oauth_redirect_port when paired with oauth_client_id, otherwise falling back to the driver's OWN app-specific PYSQL_OAUTH_REDIRECT_PORT_RANGE (8020–8024) — so a foreign client_id with no port gets pinned to the driver's default app port 8020, producing redirect_uri_mismatch (PECOBLR-4039) instead of falling through to the base default (8030). The spec principle: a caller who supplies their own client_id owns the rest of the bundle; the driver must not pin its own app-specific defaults.
Files: src/databricks/sql/auth/auth.py, tests/unit/test_auth.py
Planned coverage:

• Call get_python_sql_connector_auth_provider on an AWS host with oauth_client_id='test-custom-u2m-app', oauth_scopes=['all-apis'], oauth_redirect_port=8099 (patching DatabricksOAuthProvider._initial_get_token). Assert the resolved provider uses the caller's client_id verbatim, port_range == [8099], and _scopes_as_str == 'all-apis' (the caller's scope set forwarded verbatim, NOT the driver default 'sql offline_access'). Fails today because oauth_scopes is hardcoded to PYSQL_OAUTH_SCOPES. (AUTH-013 Case 1 — scopes forwarded verbatim)
• Call get_python_sql_connector_auth_provider on an AWS host with ONLY oauth_client_id='test-custom-u2m-app' (no oauth_redirect_port, no oauth_scopes). Assert the resolved provider uses the client_id verbatim and its oauth_manager.port_range falls through to the base default [8030] rather than the driver's app-specific default 8020–8024. Fails today because the code falls back to PYSQL_OAUTH_REDIRECT_PORT_RANGE (8020) whenever oauth_redirect_port is unset. (AUTH-013 Case 2 — foreign client_id without port must not pin driver app port 8020)

Files changed

• tests/unit/test_auth.py
• src/databricks/sql/auth/auth.py

Test plan

• tests/unit/test_auth.py::Auth::test_get_python_sql_connector_u2m_explicit_bundle_override — fails (red) against the original code, passes (green) after the fix
• tests/unit/test_auth.py::Auth::test_get_python_sql_connector_u2m_foreign_client_id_no_port — fails (red) against the original code, passes (green) after the fix

🤖 Generated by engineer-bot (bug-fix flow) — review before merge.