[coverage] Conformance findings: CLOUDFETCH-205201 #602

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-205201 [sea]: SEA/kernel path accepts the per-statement useCloudFetch:false opt-out and drops it ('no-op on kernel'), still sending disposition: INLINE_OR_EXTERNAL_LINKS and downloading results from cloud storage, so results cannot be read without object-storage access; Thrift honours it (canDownloadResult:false)
  • failing test: cloudfetch disabled — complete large result delivered with zero cloud-storage downloads [sea] (see the coverage PR diff under tests/)

Reproduce & Expected

CLOUDFETCH-205201 — With CloudFetch DISABLED at connection creation, a result large enough that the server would normally hand back external links must still be delivered COMPLETELY through the SQL connection: EVERY row…

Reproduce:

• Open a PROXIED connection with the CloudFetch opt-out set at CONNECTION
  CREATION (not toggled afterwards — see notes) and drain the result to
  completion.
• Anti-vacuity control. Re-run the SAME query on a second proxied connection
  with CloudFetch left at its DEFAULT (enabled). Drain only until the proxy has
  observed at least one cloud-storage download — a full drain is not required
  here, and the row count is deliberately NOT re-asserted on this phase (that
  is CLOUDFETCH-005's contract, and a CloudFetch-path defect must not red this
  case).

Expected (per the shared spec):

• result has exactly 250000 row(s)
• result has 2 column(s)
• col payload, row 0 is not null
• full assertion contract:

result:
- label: cloudfetch_disabled
  row_count: 250000
- label: cloudfetch_disabled
  column_count: 2
- label: cloudfetch_disabled
  column:
    name: payload
    is_not_null: true
protocol:
  thrift:
  - label: cloudfetch_disabled
    cloud_download_count:
      expected: 0
  - label: cloudfetch_enabled
    cloud_downloads_min: 1
  sea:
  - label: cloudfetch_disabled
    cloud_download_count:
      expected: 0
  - label: cloudfetch_enabled
    cloud_downloads_min: 1

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: fix(kernel): honor use_cloud_fetch when opening sessions databricks-sql-python#1019 — 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/2053