feat(kernel): surface kernel logs through Python logging on use_kernel

When the kernel backend loads, auto-initialize the kernel's
tracing -> Python logging bridge so `use_kernel=True` users see kernel
logs with no extra setup. Kernel logs land under the
`databricks.sql.kernel` logger (a child of the connector's
`databricks.sql.*` namespace), so an existing
`logging.getLogger("databricks.sql").setLevel(...)` cascades to them.

- `_errors.py` calls `databricks_sql_kernel.init_logging()` once at
  extension load (it's the canonical kernel-import site). The call is
  `getattr`-guarded so an older kernel wheel without the function still
  works — just without kernel logs.
- e2e tests assert kernel records reach the `databricks.sql.kernel`
  logger (and the pyo3 boundary under `databricks.sql.kernel.pyo3`) and
  that the level set on the logger is respected. Creds-gated per the
  existing kernel e2e convention.

Requires the companion kernel/pyo3 change
(databricks-sql-kernel#120) that exposes `init_logging()`.

Co-authored-by: Isaac
Signed-off-by: Vikrant Puppala <vikrant.puppala@databricks.com>

Author: vikrantpuppala

src/databricks/sql/backend/kernel/_errors.py

@@ -57,6 +57,17 @@
         "(into the same venv as databricks-sql-connector)."
     ) from exc
 
+# Route the kernel's Rust-side logs into Python's ``logging`` as soon as
+# the extension loads. The kernel emits under the ``databricks.sql.kernel``
+# logger (a child of the connector's ``databricks.sql`` namespace), so a
+# customer who configures ``databricks.sql`` logging gets kernel logs for
+# free with no extra setup. ``init_logging`` is idempotent on the Rust
+# side; ``getattr`` guards against an older kernel wheel that predates the
+# function so ``use_kernel=True`` still works (just without kernel logs).
+_kernel_init_logging = getattr(_kernel, "init_logging", None)
+if _kernel_init_logging is not None:
+    _kernel_init_logging()
+
 
 # Map a kernel `code` slug to the PEP 249 exception class that best
 # captures it. The match isn't a perfect 1:1 — PEP 249 has a

tests/e2e/test_kernel_backend.py

@@ -127,6 +127,73 @@ def test_fetchall_arrow(conn):
         assert table.column_names == ["a", "b"]
 
 
+# ─── Logging (Rust kernel -> Python logging bridge) ──────────────────────────
+#
+# Layer 3 of the logger-name drift guard (see also the Rust tests
+# `klog::tests::klog_emits_contract_target` and
+# `logging::tests::kernel_target_matches_contract` in the kernel repo).
+# Asserts the *customer-facing* contract end-to-end: kernel logs reach
+# Python `logging` under the `databricks.sql.kernel` logger, respect the
+# level set on it, and the pyo3 boundary surfaces under
+# `databricks.sql.kernel.pyo3`. If the kernel's tracing target or the
+# pyo3-log wiring ever drifts, these fail.
+
+import logging
+
+
+def test_kernel_logs_reach_python_logging(kernel_conn_params, caplog):
+    """A query at DEBUG produces records on the `databricks.sql.kernel`
+    logger — proving the tracing -> log -> pyo3-log -> logging chain."""
+    with caplog.at_level(logging.DEBUG, logger="databricks.sql.kernel"):
+        c = sql.connect(**kernel_conn_params)
+        try:
+            with c.cursor() as cur:
+                cur.execute("SELECT 1 AS a")
+                cur.fetchall()
+        finally:
+            c.close()
+
+    kernel_records = [
+        r for r in caplog.records if r.name.startswith("databricks.sql.kernel")
+    ]
+    assert kernel_records, (
+        "expected log records under the 'databricks.sql.kernel' logger; "
+        "the kernel tracing -> Python logging bridge did not deliver any"
+    )
+    # The core kernel logger (not just the .pyo3 child) must be present:
+    assert any(
+        r.name == "databricks.sql.kernel" for r in kernel_records
+    ), "expected core kernel records on the exact 'databricks.sql.kernel' logger"
+    # The pyo3 boundary breadcrumb must surface under the .pyo3 child:
+    assert any(
+        r.name == "databricks.sql.kernel.pyo3" for r in kernel_records
+    ), "expected pyo3-boundary records on 'databricks.sql.kernel.pyo3'"
+
+
+def test_kernel_log_level_is_respected(kernel_conn_params, caplog):
+    """At WARNING, the chatty DEBUG kernel records are filtered out
+    before reaching Python — proving level control works (and that
+    filtering happens, not that everything is forwarded unconditionally)."""
+    with caplog.at_level(logging.WARNING, logger="databricks.sql.kernel"):
+        c = sql.connect(**kernel_conn_params)
+        try:
+            with c.cursor() as cur:
+                cur.execute("SELECT 1 AS a")
+                cur.fetchall()
+        finally:
+            c.close()
+
+    debug_records = [
+        r
+        for r in caplog.records
+        if r.name.startswith("databricks.sql.kernel") and r.levelno < logging.WARNING
+    ]
+    assert not debug_records, (
+        "DEBUG/INFO kernel records leaked through at WARNING level: "
+        f"{[(r.name, r.levelname, r.getMessage()) for r in debug_records]}"
+    )
+
+
 # ── Metadata ──────────────────────────────────────────────────────