[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]: Negative query-timeout is silently accepted: DSN timeout=-1 and dbsql.WithTimeout(-1s) both configure fine and the query runs with the invalid deadline, while non-numeric and out-of-range values ARE rejected with the option named — the value is parsed but not range-validated (PECO-3011).
  • failing test: TestQueryTimeoutOptionValueValidation (see the coverage PR diff under tests/)
• STATEMENT-025 [sea]: Same negative-value gap on the SEA/kernel leg, and sharper: the kernel backend REFUSES any non-zero dbsql.WithTimeout up front ("not supported by the kernel backend") yet still ACCEPTS WithTimeout(-1s) and DSN timeout=-1 and runs the query — positive refused, negative waved through (PECO-3011).
  • failing test: TestQueryTimeoutOptionValueValidation (see the coverage PR diff under tests/)
• STATEMENT-025: Negative query-timeout values are silently accepted instead of rejected: timeout=-1 in the DSN and dbsql.WithTimeout(-1s) both configure successfully and a query then runs with the invalid deadline (behaving as "unlimited"), while non-numeric and out-of-range values ARE correctly rejected with a message naming the option — proving the value is parsed but not range-validated (PECO-3011). Affects both the Thrift and SEA/kernel backends; notably the kernel backend refuses any non-zero WithTimeout up front yet still accepts a negative one.

Reproduce & Expected

STATEMENT-025 — Validates that an INVALID value for the query-timeout option is REJECTED with an error at configuration time, on every surface that accepts the option, instead of being silently accepted and coerced…

Reproduce:

SELECT 1
SELECT 1

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)
• completes without an exception
• completes without an exception
• completes without an exception
• full assertion contract:

result:
- label: property_non_numeric
  error:
    contains:
    - timeout
- label: property_negative
  error:
    contains:
    - timeout
- label: property_unrepresentable
  error:
    contains:
    - timeout
- label: set_option_non_numeric
  error:
    contains:
    - timeout
- label: set_option_negative
  error:
    contains:
    - timeout
- label: set_option_unrepresentable
  error:
    contains:
    - timeout
- label: property_zero_unlimited
  no_exception: true
- label: property_zero_unlimited
  row_count: 1
- label: property_max_positive
  no_exception: true
- label: property_max_positive
  row_count: 1
- label: set_option_valid_zero
  no_exception: true
- label: set_option_valid_one
  no_exception: true
- label: set_option_valid_max
  no_exception: true

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: fix(csharp): validate SEA query timeout values adbc-drivers/databricks#689 — 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/1692