fix(kernel): harden log-bridge init + address review feedback

Review feedback from PR #824 (gopalldb):

- P1: guard the init_logging() call against throwing, not just a missing
  function. A panic across the PyO3 boundary surfaces as
  pyo3_runtime.PanicException (a BaseException, not Exception), so a bare
  call could escape module import and fail every use_kernel=True
  connection over a non-essential logging feature. Wrap in
  try/except BaseException, log a debug breadcrumb, continue. This also
  neutralizes the idempotency concern regardless of the Rust impl.
- P2: soften the level-control test docstring to make clear it asserts
  the effective customer-visible outcome (sub-threshold records don't
  surface), not source-side suppression — caplog filters after the FFI.
- P2: downgrade the databricks.sql.kernel.pyo3 assertion to a soft
  warning so a benign kernel change to the boundary breadcrumb target
  doesn't break the connector e2e suite. The core
  databricks.sql.kernel contract is still hard-asserted.

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

Author: vikrantpuppala

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

@@ -38,6 +38,8 @@
 
 from __future__ import annotations
 
+import logging
+
 from databricks.sql.exc import (
     DatabaseError,
     Error,
@@ -61,12 +63,26 @@
 # 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).
+# free with no extra setup.
+#
+# This is a best-effort, non-essential feature: it must never take down
+# ``use_kernel=True`` for a process. ``getattr`` guards against an older
+# kernel wheel that predates the function. The ``try`` guards against the
+# call itself throwing — note ``except BaseException`` is deliberate: a
+# panic raised across the PyO3 boundary surfaces as
+# ``pyo3_runtime.PanicException``, which derives from ``BaseException``
+# (not ``Exception``), so a narrower clause would let it escape module
+# import and fail every kernel-backed connection. The kernel side is
+# idempotent and returns rather than panics on a double install, but we
+# do not rely on that here — the guard holds regardless of the Rust impl.
 _kernel_init_logging = getattr(_kernel, "init_logging", None)
 if _kernel_init_logging is not None:
-    _kernel_init_logging()
+    try:
+        _kernel_init_logging()
+    except BaseException as exc:  # noqa: BLE001 - see comment above re: PanicException
+        logging.getLogger(__name__).debug(
+            "kernel log bridge init failed; continuing without it: %r", exc
+        )
 
 
 # Map a kernel `code` slug to the PEP 249 exception class that best

tests/e2e/test_kernel_backend.py

@@ -160,20 +160,38 @@ def test_kernel_logs_reach_python_logging(kernel_conn_params, caplog):
         "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:
+    # The core kernel logger (not just any child) must be present — this
+    # is the customer-facing contract.
     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'"
+    # The pyo3-boundary breadcrumb (`databricks.sql.kernel.pyo3`) is a
+    # nice-to-have, but the exact sub-target is a kernel-internal naming
+    # detail — assert softly so a benign kernel change to the boundary
+    # breadcrumbs doesn't break the connector e2e suite.
+    if not any(r.name == "databricks.sql.kernel.pyo3" for r in kernel_records):
+        import warnings
+
+        warnings.warn(
+            "no 'databricks.sql.kernel.pyo3' boundary records seen; "
+            "the kernel may have changed its pyo3 breadcrumb target",
+            stacklevel=2,
+        )
 
 
 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)."""
+    """At WARNING on the kernel logger, no DEBUG/INFO kernel records reach
+    `caplog.records` — i.e. level control on `databricks.sql.kernel`
+    behaves like any other Python logger.
+
+    Scope note: `caplog.at_level` sets the logger's level and attaches a
+    handler, so this asserts the *effective* outcome a customer sees
+    (sub-threshold records don't surface), not specifically that the Rust
+    side suppressed them at source. A DEBUG record that crossed the FFI
+    would still be dropped by Python's level check before reaching
+    `caplog`. Source-side suppression (and its per-record FFI cost
+    avoidance) is covered by the kernel-side filtering, not asserted
+    here."""
     with caplog.at_level(logging.WARNING, logger="databricks.sql.kernel"):
         c = sql.connect(**kernel_conn_params)
         try: