Summary
Cursor.close() does not free the server-side statement handle for async-submitted commands when get_execution_result() was never called. The handle leaks until the session closes (where backend-specific sweeps may or may not catch it).
Repro
import databricks.sql
with databricks.sql.connect(...) as conn:
cur = conn.cursor()
cur.execute("SELECT * FROM huge_table", async_op=True)
# User decides not to wait for the result.
cur.close()
# Server-side ExecutedAsyncStatement still tracked until conn.close().Root cause
Cursor.close() at src/databricks/sql/client.py:1713-1718 only nulls active_command_id and closes active_result_set — but for the async-submit-without-fetch case, active_result_set is None, so backend.close_command(active_command_id) is never invoked.
def close(self) -> None:
"""Close cursor"""
self.open = False
self.active_command_id = None
if self.active_result_set:
self._close_and_clear_active_result_set()Scope
Affects all three backends: Thrift, SEA, and the new kernel backend. Each one tracks the async handle differently (Thrift via Thrift-server-side state; SEA via the SEA statement; kernel via _async_handles dict), but the shared Cursor.close() path doesn't notify any of them about the unfetched async handle.
Suggested fix
Single change in shared Cursor.close():
def close(self) -> None:
self.open = False
if self.active_result_set:
self._close_and_clear_active_result_set()
elif self.active_command_id is not None:
# async submission that never had get_execution_result called —
# the result-set close path didn't fire, so issue an explicit
# close_command to free the server-side handle.
try:
self.backend.close_command(self.active_command_id)
except Exception as exc:
logger.warning("close_command on cursor close failed: %s", exc)
self.active_command_id = NoneSafe across all backends: Thrift's close_command sends TCloseOperation (valid call), SEA's sends a cancel/close, kernel's is already tolerant of unknown ids (no-op).
Surfaced by
Review of PR #787 (kernel backend). Documented as P0 #1 in #787 (comment) — but the leak is pre-existing on Thrift and SEA too, not specific to the kernel backend.
Summary
Cursor.close()does not free the server-side statement handle for async-submitted commands whenget_execution_result()was never called. The handle leaks until the session closes (where backend-specific sweeps may or may not catch it).Repro
Root cause
Cursor.close()atsrc/databricks/sql/client.py:1713-1718only nullsactive_command_idand closesactive_result_set— but for the async-submit-without-fetch case,active_result_setisNone, sobackend.close_command(active_command_id)is never invoked.Scope
Affects all three backends: Thrift, SEA, and the new kernel backend. Each one tracks the async handle differently (Thrift via Thrift-server-side state; SEA via the SEA statement; kernel via
_async_handlesdict), but the sharedCursor.close()path doesn't notify any of them about the unfetched async handle.Suggested fix
Single change in shared
Cursor.close():Safe across all backends: Thrift's
close_commandsendsTCloseOperation(valid call), SEA's sends a cancel/close, kernel's is already tolerant of unknown ids (no-op).Surfaced by
Review of PR #787 (kernel backend). Documented as P0 #1 in #787 (comment) — but the leak is pre-existing on Thrift and SEA too, not specific to the kernel backend.