[coverage] Conformance findings: STATEMENT-025

Bắt đầu bằng cách đọc test bị lỗi test_cancel_during_result_fetch_is_prompt_and_signal_only trong coverage PR và chạy test đó trên cả các đường dẫn SEA của thrift và Rust-kernel. So sánh hành vi của driver với contract STATEMENT-025 và PR 362; được coi là hoàn thành khi việc hủy fetch diễn ra nhanh chóng, báo lỗi hủy với trạng thái SQL HY008 và các câu lệnh tiếp theo vẫn hoạt động.

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-python. Each finding is committed as an expected-failure (xfail) test in the coverage PR — the test asserts the CORRECT (post-fix) behavior and stays red until THIS driver (databricks/databricks-sql-python) is fixed, then flips green as a tripwire.

Findings

• STATEMENT-025 [thrift]: Cancel during result FETCH unwinds the fetching thread with wrong-state RESOURCE_DOES_NOT_EXIST ('Command does not exist') instead of a cancellation error
  • failing test: test_cancel_during_result_fetch_is_prompt_and_signal_only (see the coverage PR diff under tests/)
• STATEMENT-025 [sea]: Cancel issued during a result FETCH is silently dropped on the Rust-kernel SEA path, so the in-flight fetch never unwinds and drains to natural completion
  • failing test: test_cancel_during_result_fetch_is_prompt_and_signal_only (see the coverage PR diff under tests/)
• STATEMENT-025: Cursor.cancel() issued during a result FETCH is not honoured on either backend: thrift's interrupted fetch unwinds with wrong-state RESOURCE_DOES_NOT_EXIST instead of a cancellation error, and the Rust-kernel SEA path drops the cancel entirely so the fetch drains to natural completion; after a sync execute() returns, no cancellable in-flight operation is registered for the fetch phase

Reproduce & Expected

STATEMENT-025 — Validates cancellation while a result set is being FETCHED (not merely while the statement is EXECUTING -- that is STATEMENT-015/022).

Reproduce:

SELECT * FROM main.tpcds_sf1_delta.catalog_returns
SELECT 1
SELECT * FROM main.tpcds_sf1_delta.catalog_returns

Expected (per the shared spec):

• completes without an exception
• completes without an exception
• completes without an exception
• result has exactly 1 row(s)
• completes without an exception
• full assertion contract:

result:
- label: idle_cancel
  no_exception: true
- label: mid_fetch_cancel
  no_exception: true
- label: mid_fetch_cancel
  elapsed_seconds_range:
    min: 0
    max: 5
- label: cancelled_fetch
  error:
    contains:
    - cancel
    - cancelled
    - canceled
    - aborted
- label: cancelled_fetch
  sql_state: HY008
- label: cancelled_fetch
  elapsed_seconds_range:
    min: 0
    max: 30
- label: reused_statement
  no_exception: true
- label: reused_statement
  row_count: 1
- label: concurrent_cancel
  no_exception: true
- label: concurrent_cancelled_fetch
  elapsed_seconds_range:
    min: 0
    max: 30

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-odbc/pull/362 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-python; the reference PR is for cross-referencing the intended behavior, NOT a change to this repo.
• Coverage PR carrying the reproducing xfail test(s): https://github.com/databricks/databricks-driver-test/pull/1562