[coverage] Conformance findings: STATEMENT-023

[peco-engineer-bot]

Summary

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

Findings

• STATEMENT-023 [thrift, sea]: Query timeout reports the internal error-code enum name (STATEMENT_EXECUTION_TIMEOUT / OPERATION_TIMEOUT_ERROR) in SQLSTATE instead of the standard "timeout expired" state HYT00 — DatabricksTimeoutException passes internalError.toString() into the SQLSTATE slot, so portable SQLSTATE-based timeout handling cannot recognise the timeout (same enforcement family as databricks-odbc#136)
  • failing test: testQueryTimeoutEnforcedWithoutBlocking (see the coverage PR diff under tests/)
• STATEMENT-023: Query timeout reports the internal error-code enum name (STATEMENT_EXECUTION_TIMEOUT / OPERATION_TIMEOUT_ERROR) in SQLSTATE instead of the standard "timeout expired" state HYT00, on both thrift and sea — DatabricksTimeoutException passes internalError.toString() into the SQLSTATE slot, so portable SQLSTATE-based timeout handling cannot recognise the timeout (same enforcement family as databricks-odbc#136)

Reproduce & Expected

STATEMENT-023 — Validates that a configured client-side query timeout is ENFORCED at execution time -- not merely stored and echoed back by the getter (STATEMENT-021 asserts only that some timeout error surfaces;…

Reproduce:

SELECT COUNT(*) FROM range(0, 40000000) a JOIN range(0, 40000000) b ON a.id % 5000 = b.id % 5000 -- timeout nonce <unique-per-run>
SELECT 1
SELECT COUNT(*) FROM range(0, 200000000)

Expected (per the shared spec):

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

result:
- label: timed_out
  error:
    contains:
    - timeout
    - timed out
    - cancel
- label: timed_out
  sql_state: HYT00
- label: timed_out
  elapsed_seconds_range:
    min: 4
    max: 25
- label: reused_statement
  no_exception: true
- label: reused_statement
  row_count: 1
- label: unlimited_timeout
  no_exception: true
- label: unlimited_timeout
  row_count: 1

Context

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

[jay-xiao446]

This is a false alarm as HYT00 is ODBC specific and JDBC has the correct assertion. Any suggestion to denoise this? cc @eric-wang-1990 @sreekanth-db