[coverage] Conformance findings: STATEMENT-025

Beginne damit, den fehlschlagenden Test test_cancel_during_result_fetch_is_prompt_and_signal_only im Coverage-PR zu lesen und ihn sowohl für die thrift- als auch für die Rust-kernel-SEA-Pfade auszuführen. Vergleiche das Verhalten des Treibers mit dem Vertrag STATEMENT-025 und PR 362; als erfüllt gilt dies, wenn die Abbruchanforderung beim Abruf umgehend wirksam wird, einen Abbruchfehler mit dem SQL-Status HY008 meldet und nachfolgende Anweisungen weiterhin funktionieren.

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