[coverage] Conformance findings: CLOUDFETCH-016,CLOUDFETCH-018,ERRORRECOV-014

[peco-engineer-bot]

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

• CLOUDFETCH-016 [thrift]: On the CloudFetch error path the per-operation close is never sent: after a persistently failing chunk download (HTTP 500), closing the cursor and connection issues CloseOperation=0 on Thrift even with an explicit cur.close(); session-level CloseSession does fire, so the statement handle stays orphaned server-side until the SQL Gateway's ~1h CommandInactivityTimeout
  • failing test: test_cloud_fetch_explicit_close_operation_on_download_error (see the coverage PR diff under tests/)
• CLOUDFETCH-018 [thrift]: A non-numeric CloudFetch chunk-budget value (max_download_threads="abc") is neither validated nor ignored — it is passed straight to ThreadPoolExecutor(max_workers="abc") in ResultFileDownloadManager, raising TypeError and failing the query; an unparseable tuning value should be ignored so the driver keeps its default
  • failing test: test_invalid_chunk_buffer_bound_is_tolerated_not_fatal (see the coverage PR diff under tests/)
• ERRORRECOV-014 [thrift]: An inconsistent retry-backoff bound pair (max < min) is rejected instead of corrected: ThriftDatabricksClient._initialize_retry_args raises ValueError('Invalid configuration enables retries with retry delay min(=..) > max(=..)') so databricks.sql.connect() fails outright over a tuning typo, rather than clamping max up to min and warning
  • failing test: test_retry_wait_max_below_min_is_corrected_not_fatal (see the coverage PR diff under tests/)
• ERRORRECOV-014 [sea]: An inconsistent retry-backoff bound pair (max < min) is forwarded verbatim to the Rust kernel as retry_min_wait_secs/retry_max_wait_secs, which aborts on an internal min <= max assertion — surfaced as an uncatchable pyo3_runtime.PanicException at stmt.execute(); the pair should be clamped and warned about, never panic
  • failing test: test_retry_wait_max_below_min_is_corrected_not_fatal (see the coverage PR diff under tests/)
• ERRORRECOV-014: An inconsistent retry-backoff bound pair (max < min) is rejected instead of corrected on both backends: Thrift raises ValueError from ThriftDatabricksClient._initialize_retry_args so connect() fails outright, and kernel forwards the pair verbatim to the Rust kernel which aborts on an internal min <= max assertion, surfacing as an uncatchable pyo3_runtime.PanicException at execute — a tuning typo should be clamped and warned about, never fatal and certainly never a panic

Reproduce & Expected

CLOUDFETCH-016 — Even when a CloudFetch chunk download fails (server returns HTTP 500), the driver MUST still send CloseStatement on Dispose — server-side cleanup happens on the error path too, not only on success.

Reproduce:

• CloudFetch query whose chunk download fails with HTTP 500 (expect an exception).

Expected (per the shared spec):

• full assertion contract:

result:
- exception_thrown: true
protocol:
  thrift:
  - call_min:
      method: CloseOperation
      min: 1
  sea:
  - call_min:
      operation: CloseStatement
      min: 1

CLOUDFETCH-018 — Validates that an out-of-range or non-numeric value for the CloudFetch in-memory chunk budget NEVER fails connection open: the driver clamps a value above its ceiling, ignores a value it cannot parse…

Reproduce:

SELECT * FROM main.tpcds_sf1_delta.catalog_returns

Expected (per the shared spec):

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

result:
- connection_not_null: true
  description: "Connection opens for {case} ({value}) \u2014 the value is never fatal"
- no_exception: true
- row_count_min: 1
  description: The result is still delivered in full for {case}

ERRORRECOV-014 — Validate that a backoff-bound typo — a configured MAXIMUM wait below the configured MINIMUM — does NOT fail the connection.

Reproduce:

SELECT 1 AS test_value

Expected (per the shared spec):

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

result:
- connection_not_null: true
  description: "max < min is corrected, not rejected \u2014 the connection opens"
- no_exception: true
- row_count: 1
  description: The retried query still succeeds under the corrected policy
protocol:
  thrift:
  - call_min:
      method: ExecuteStatement
      min: 2
  sea:
  - call_min:
      operation: ExecuteStatement
      min: 2

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-odbc/pull/181 — 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/1110