[coverage] Conformance findings: CLOUDFETCH-012,CLOUDFETCH-204301 #601

Summary

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

Findings

• CLOUDFETCH-012 [sea]: SEA/kernel path honors no CloudFetch disable: the per-statement useCloudFetch is explicitly discarded ("no-op on kernel") and no client-level default is forwarded into the kernel result configuration, so a caller that disabled CloudFetch still gets external-link delivery (2 cloud-storage GETs); the Thrift path honors it
  • failing test: CloudFetch disabled — zero cloud downloads, result delivered through the SQL connection [sea] (see the coverage PR diff under tests/)
• CLOUDFETCH-204301 [sea]: with CloudFetch disabled, a 250,000-row/32 MB result is still delivered over cloud storage on the SEA/kernel path (rows are complete, but 2 external-link GETs occur instead of coming through the SQL connection); same root cause as the CLOUDFETCH-012 SEA finding
  • failing test: CloudFetch disabled delivers a complete multi-chunk result — 250,000 generator rows intact [sea] (see the coverage PR diff under tests/)

Reproduce & Expected

CLOUDFETCH-012 — Validates that when the connection-level CloudFetch toggle is set to false (C#/Rust adbc.databricks.cloudfetch.enabled, JDBC EnableQueryResultDownload=0, Python use_cloud_fetch=False, Go `WithC…

Reproduce:

• Execute query with CloudFetch disabled

Expected (per the shared spec):

• Query completes successfully using fallback result fetching
• Query returns valid result with data
• No cloud_download HTTP GET requests should occur. Requires a proxied connection so the proxy can observe zero downloads. C# (Thrift): falls back to FetchResults. Rust (SEA): falls back to inline SEA result paging.
• C# (Thrift): FetchResults should be used for standard result fetching

CLOUDFETCH-204301 — With CloudFetch disabled at the connection level, a result far larger than one chunk must still be delivered COMPLETE through the SQL connection: every row, in order, with values intact.

Reproduce:

• Connection left at the driver default (CloudFetch enabled). Execute the query
  and drain it fully. Establishes that this result is delivered via external
  links on this driver and warehouse.
• A SECOND connection with the connection-level CloudFetch toggle set to false
  (see connection_params). Execute the SAME query and drain it fully.

Expected (per the shared spec):

• result has exactly 250000 row(s)
• full assertion contract:

result:
- label: disabled
  exception_thrown: false
- label: disabled
  row_count: 250000
- label: disabled
  row_values_match_generator: true
  description: 'Row i (0-based, ordered by id) carries id == i and payload == the
    lowercase

    hex SHA-512 of the decimal string of i -- no dropped, duplicated or

    re-ordered rows. Equivalent accepted form: hash the drained rows as

    "<id>\t<payload>\n" per row and compare a single digest (the reference

    end-to-end test compares sha256 =

    a25ada4c6c476b53e97eb6e8a945e9ce4c14cc432c7ad672dc6fb607d660c86a).

    '
protocol:
  thrift:
  - label: enabled_control
    cloud_downloads_min: 1
  - label: disabled
    cloud_downloads: 0
  sea:
  - label: enabled_control
    cloud_downloads_min: 1
  - label: disabled
    cloud_downloads: 0

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: fix(kernel): honor the client CloudFetch default #574 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-nodejs; 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/2046