[coverage] Conformance findings: STATEMENT-025

[peco-engineer-bot]

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-go. 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-go) is fixed, then flips green as a tripwire.

Findings

• STATEMENT-025 [thrift]: Cancel does not abort an in-flight CloudFetch batch download: the drain stays parked and only unwinds when the 60s injected stall expires, so the spec's 30s unwind bound fails and no cancellation-classified error is ever surfaced
  • failing test: TestCancelDuringBatchDownloadReportsCancellationNotTransportError (see the coverage PR diff under tests/)
• STATEMENT-025 [sea]: Same as Thrift on the SEA/kernel backend: cancel does not abort the in-flight CloudFetch batch download, so the drain unwinds only when the injected 60s stall expires and the spec's 30s bound fails
  • failing test: TestCancelDuringBatchDownloadReportsCancellationNotTransportError (see the coverage PR diff under tests/)
• STATEMENT-025: Cancelling a query whose fetch is parked inside a CloudFetch batch download does not abort the in-flight download: the drain ignores the cancel and only unwinds when the stalled blob GET completes (60s injected stall → no unwind within 30s of cancel), on both the Thrift and SEA/kernel backends, so an application cannot cancel a stuck result fetch and never sees a cancellation-classified error

Reproduce & Expected

STATEMENT-025 — When an application cancels while a fetch is BLOCKED retrieving the next batch of results, the error the fetch surfaces must be identifiable as THE CANCELLATION THE APPLICATION REQUESTED -- not as a…

Reproduce:

• Stall the first CloudFetch batch download for duration_seconds so the fetch
  parks inside the download rather than completing between rowsets.
• Execute the query and begin draining its result on a background thread, so the
  drain can be observed to block while the main thread issues the cancel. The
  result must be large enough to be delivered via CloudFetch external links.
• Wait until the drain is genuinely blocked in the batch download (the stalled
  download is in flight), so the cancel lands MID-DOWNLOAD rather than between
  rowsets. A driver-agnostic fixed wait is sufficient because the injected stall
  lasts far longer than this wait.
• Cancel while the drain is parked in the download. This aborts the in-flight
  download, so the driver's batch retrieval returns a failure status -- the
  moment the classification under test is decided.
• Wait for the drain to unwind after the cancel

Expected (per the shared spec):

• full assertion contract:

result:
- label: cancelled_fetch
  either_condition_true:
  - sql_state: HY008
  - error:
      contains:
      - cancel
      - cancelled
      - canceled
      - abort
  - no_exception: true
- label: cancelled_fetch
  elapsed_seconds_range:
    max: 30
protocol:
  thrift:
  - either_condition_true:
    - cloud_downloads_min: 1
  sea:
  - either_condition_true:
    - cloud_downloads_min: 1

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-odbc/pull/382 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-go; 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/1565