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
- SESSION-017 [thrift]: Thrift:
_socket_timeout=0 becomes a 0.0s urllib3 timeout (setTimeout(timeout and float(timeout)*1000.0) short-circuits on 0), so urllib3 rejects every request with "timeout cannot be set to a value less than or equal to 0" and the connection cannot open — 0 should select the default deadline (or none), as the kernel path does
- failing test:
test_request_timeout_bounds_delayed_request_and_zero_selects_default (see the coverage PR diff under tests/)
- SESSION-017 [sea]: kernel/SEA: a positive
_socket_timeout correctly aborts a delayed status request, but the surfaced OperationalError reads "error sending request for url (...)" with no timeout/deadline wording — the underlying reqwest timeout source is dropped, so callers cannot distinguish a deadline abort from an unrelated transport failure
- failing test:
test_request_timeout_bounds_delayed_request_and_zero_selects_default (see the coverage PR diff under tests/)
Reproduce & Expected
SESSION-017 — Validates the connection-level HTTP request/socket timeout option: the per-request transport deadline that applies to every request the driver issues on a connection (connect through response-body co…
Reproduce:
SELECT count(*) FROM range(1, 100000000)
SELECT 1 AS test_value
Expected (per the shared spec):
- completes without an exception
- result has exactly 1 row(s)
- full assertion contract:
result:
- error_thrown: true
context: positive_timeout
description: 'The 2-second deadline aborts the delayed request rather than waiting
out the
5-second delay.
'
- error_message_contains_any:
- timeout
- timed out
- deadline
- cancel
context: positive_timeout
description: 'Case-insensitive. The error identifies a timeout/deadline rather than
an
unrelated transport or server failure.
'
- no_exception: true
context: zero_timeout
description: 'With the option set to 0 the 5s-delayed request is NOT aborted - the
query
completes. Satisfied whether the driver reads 0 as "use my default deadline"
or as "no deadline"; only an immediate zero-length deadline fails here.
'
- row_count: 1
context: zero_timeout
description: SELECT 1 returns its single row, proving the request completed normally.
Context
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
_socket_timeout=0becomes a 0.0s urllib3 timeout (setTimeout(timeout and float(timeout)*1000.0)short-circuits on 0), so urllib3 rejects every request with "timeout cannot be set to a value less than or equal to 0" and the connection cannot open — 0 should select the default deadline (or none), as the kernel path doestest_request_timeout_bounds_delayed_request_and_zero_selects_default(see the coverage PR diff undertests/)_socket_timeoutcorrectly aborts a delayed status request, but the surfacedOperationalErrorreads "error sending request for url (...)" with no timeout/deadline wording — the underlying reqwest timeout source is dropped, so callers cannot distinguish a deadline abort from an unrelated transport failuretest_request_timeout_bounds_delayed_request_and_zero_selects_default(see the coverage PR diff undertests/)Reproduce & Expected
SESSION-017 — Validates the connection-level HTTP request/socket timeout option: the per-request transport deadline that applies to every request the driver issues on a connection (connect through response-body co…
Reproduce:
Expected (per the shared spec):
Context