You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(backend/kernel): retain parent Statement for async-submitted commands
The kernel's `Statement.close()` invalidates any executed handle the
Statement produced (see `databricks-sql-kernel/src/statement/validity.rs`
and `mutable::close`). Today `KernelDatabricksClient.execute_command`
closes `stmt` in `finally` regardless of `async_op` — which is correct
for the sync path (`stmt.execute()` returns a fully-materialised result
before the close) but wrong for the async path: as soon as the user
calls `cursor.execute_async(...)` and tries to poll or fetch, the
async handle is already invalidated and the next operation raises
"executed-statement handle has been invalidated by a re-execute on its
parent Statement".
This makes the entire async surface
(`execute_async` + `is_query_pending`/`get_query_state` +
`get_async_execution_result`) effectively non-functional on the kernel
backend today.
Fix: when `async_op=True`, retain the parent Statement in a new
`_async_statements` dict alongside `_async_handles`, and close it in
`close_command`, `close_session`, and `get_execution_result` (which
already closes the async handle once the result stream is produced).
The sync path is unchanged.
Discovered via the python-comparator audit harness running the
`STATEMENT_ASYNC` suite — the kernel side produced 0 HTTP requests
because every async cursor operation short-circuited locally on the
invalidated handle.
Test:
conn = sql.connect(..., use_kernel=True)
cur = conn.cursor()
cur.execute_async("SELECT 1 AS x")
while cur.is_query_pending(): time.sleep(0.2)
cur.get_async_execution_result()
assert cur.fetchall() == [(1,)]
Previously raised KernelError("InvalidStatementHandle: …") on
`is_query_pending`; now succeeds.
Signed-off-by: Vikrant Puppala <vikrant.puppala@databricks.com>
0 commit comments