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
importdatabricks.sqlwithdatabricks.sql.connect(...) asconn:
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.
defclose(self) ->None:
"""Close cursor"""self.open=Falseself.active_command_id=Noneifself.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():
defclose(self) ->None:
self.open=Falseifself.active_result_set:
self._close_and_clear_active_result_set()
elifself.active_command_idisnotNone:
# 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)
exceptExceptionasexc:
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.