[coverage] Conformance findings: AUTH-013

[peco-engineer-bot]

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-python. Each finding is committed as an expected-failure (xfail) test in the coverage PR — the test asserts the CORRECT (post-fix) behavior and stays red until THIS driver (databricks/databricks-sql-python) is fixed, then flips green as a tripwire.

Findings

• AUTH-013 [thrift]: U2M partial override: a caller-supplied oauth_client_id without oauth_redirect_port still gets the connector's own default app port 8020 (auth.py honours oauth_redirect_port only when paired with oauth_client_id, else falls back to PYSQL_OAUTH_REDIRECT_PORT_RANGE), so the foreign app's browser redirect fails with redirect_uri_mismatch (PECOBLR-4039)
  • failing test: test_oauth_u2m_explicit_bundle_override (see the coverage PR diff under tests/)

Reproduce & Expected

AUTH-013 — Verifies that a caller-supplied U2M OAuth identity is honoured verbatim, and that a caller who supplies their OWN client_id also OWNS the rest of the bundle - the driver must NOT pin its own default…

Reproduce:

• Case 1 - begin a U2M connect supplying client_id test-custom-u2m-app,
  scopes ["all-apis"] and redirect_port 8099; capture the resolved bundle at the
  same observation point AUTH-012 uses (authorization URL / callback listener /
  proxied request). The interactive login is not completed.
• Case 2 - repeat supplying ONLY client_id test-custom-u2m-app, leaving scopes
  and redirect_port unset.

Expected (per the shared spec):

• The supplied client_id is sent unchanged - no default substitution, in both cases.
• {'oauth_u2m_override_scopes_verbatim': {'values': ['all-apis'], 'description': "Case 1: the caller's scope set is forwarded verbatim, even when it differs from\nthe driver's default sql offline_access.\n"}}
• Case 1: the localhost callback / redirect URI uses the caller's port 8099, not any driver default.
• Case 2 (client_id only): the driver does NOT apply its own default app's app-specific pins. Concretely, a driver whose DEFAULT bundle uses databricks-sql-python + port 8020 must NOT redirect to 8020 here - with a foreign client_id the unsupplied port falls through to the base kernel default (8030). Likewise the scope set is not pinned to that binding's app-specific list.

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-sql-kernel/pull/247 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-python; the reference PR is for cross-referencing the intended behavior, NOT a change to this repo.
• Coverage PR carrying the reproducing xfail test(s): https://github.com/databricks/databricks-driver-test/pull/1285