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
- CLOUDFETCH-019 [thrift]: A non-positive client-side CloudFetch knob value (WithMaxDownloadThreads(-1)) is not validated: session open and execution succeed but the download worker pool starts no workers, so no Arrow batch is produced and the first row read fails with "row number 0 is not contained in any arrow batch: EOF" instead of degrading to the driver default (the above-maximum shape conforms).
- failing test:
TestInvalidClientSideCloudFetchKnobValueDoesNotFailSessionOpen (see the coverage PR diff under tests/)
- CLOUDFETCH-019: A non-positive client-side CloudFetch knob value (WithMaxDownloadThreads(-1)) is not validated: session open and execution succeed but the download worker pool starts no workers, so the result stream produces no Arrow batch and the first row read fails with "row number 0 is not contained in any arrow batch: EOF" instead of degrading to the driver default (databricks-odbc#227 pre-screens and warns).
Reproduce & Expected
CLOUDFETCH-019 — A bad value for a client-side CloudFetch tuning knob must degrade to the driver default, never fail the connection.
Reproduce:
- Same knob as CLOUDFETCH-018 (this driver's client-side CloudFetch knob), set
to a value that is not a positive integer — e.g.
adbc.databricks.cloudfetch.max_chunks_in_memory = "not-a-number". Use "0" or
"-1" where the driver's option surface is typed and cannot carry a
non-numeric string.
- The same knob set far above any plausible ceiling — e.g. "100000" (the
reference kernel clamps at 256).
Expected (per the shared spec):
- completes without an exception
- result has at least 1 row(s)
- completes without an exception
- result has at least 1 row(s)
- [thrift]
OpenSession request configuration.cloudfetch_max_chunks_in_memory is absent
- [sea]
CreateSession request session_confs.cloudfetch_max_chunks_in_memory is absent
- full assertion contract:
result:
- label: not_a_positive_integer
no_exception: true
- label: not_a_positive_integer
row_count_min: 1
- label: above_maximum
no_exception: true
- label: above_maximum
row_count_min: 1
protocol:
thrift:
- label: not_a_positive_integer
request_field:
method: OpenSession
path: configuration.cloudfetch_max_chunks_in_memory
present: false
- label: not_a_positive_integer
cloud_downloads_min: 1
sea:
- label: not_a_positive_integer
request_field:
operation: CreateSession
path: session_confs.cloudfetch_max_chunks_in_memory
present: false
- label: not_a_positive_integer
cloud_downloads_min: 1
Context
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
TestInvalidClientSideCloudFetchKnobValueDoesNotFailSessionOpen(see the coverage PR diff undertests/)Reproduce & Expected
CLOUDFETCH-019 — A bad value for a client-side CloudFetch tuning knob must degrade to the driver default, never fail the connection.
Reproduce:
to a value that is not a positive integer — e.g.
adbc.databricks.cloudfetch.max_chunks_in_memory = "not-a-number". Use "0" or"-1" where the driver's option surface is typed and cannot carry a
non-numeric string.
reference kernel clamps at 256).
Expected (per the shared spec):
OpenSessionrequestconfiguration.cloudfetch_max_chunks_in_memoryis absentCreateSessionrequestsession_confs.cloudfetch_max_chunks_in_memoryis absentContext