[coverage] Conformance findings: CLOUDFETCH-012

Inizia con il test xfail della PR di copertura per CLOUDFETCH-012 e con i percorsi del driver che gestiscono le opzioni di executeStatement e databricks.cloudfetch.enabled. Confronta il comportamento previsto con la PR di riferimento 225, quindi traccia le richieste ExecuteStatement e CreateSession di SEA/kernel. Il lavoro è completato quando il contratto è soddisfatto: vengono utilizzati INLINE e ARROW_STREAM, can_cloud_download è assente, viene restituita almeno una riga e ci sono zero chiamate a cloud_download.

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 silently ignores CloudFetch-disable: both per-statement useCloudFetch:false (driver logs "no-op on kernel") and the connection-level databricks.cloudfetch.enabled=false extraParameter are dropped, so ExecuteStatement still sends disposition=INLINE_OR_EXTERNAL_LINKS instead of INLINE
  • failing test: CLOUDFETCH-012 — cloudfetch disabled: disposition=INLINE, no can_cloud_download conf, 0 cloud downloads [sea] (see the coverage PR diff under tests/)
• CLOUDFETCH-012: SEA/kernel path silently ignores CloudFetch-disable: both per-statement executeStatement(sql, {useCloudFetch:false}) (driver logs "no-op on kernel") and the connection-level databricks.cloudfetch.enabled=false extraParameter are dropped, so ExecuteStatement still sends disposition=INLINE_OR_EXTERNAL_LINKS instead of INLINE and callers who disable CloudFetch keep receiving external links

Reproduce & Expected

CLOUDFETCH-012 — Validates that when CloudFetch is disabled, no CloudFetch activity occurs and results are fetched via the driver's inline result path instead.

Reproduce:

• Execute query with CloudFetch disabled

Expected (per the shared spec):

• completes without an exception
• result has at least 1 row(s)
• [thrift] ExecuteStatement request canDownloadResult == False
• [thrift] exactly 0 cloud_download call(s)
• [sea] ExecuteStatement request disposition == 'INLINE'
• [sea] ExecuteStatement request format == 'ARROW_STREAM'
• [sea] CreateSession request session_confs.can_cloud_download is absent
• [sea] exactly 0 cloud_download call(s)
• full assertion contract:

result:
- no_exception: true
- row_count_min: 1
- result_not_null_with_data: true
protocol:
  thrift:
  - request_field:
      method: ExecuteStatement
      path: canDownloadResult
      equals: false
  - call_min:
      method: FetchResults
      min: 1
  - call_count:
      method: cloud_download
      expected: 0
  sea:
  - request_field:
      operation: ExecuteStatement
      path: disposition
      equals: INLINE
  - request_field:
      operation: ExecuteStatement
      path: format
      equals: ARROW_STREAM
  - request_field:
      operation: CreateSession
      path: session_confs.can_cloud_download
      present: false
  - call_count:
      method: cloud_download
      expected: 0

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-sql-kernel/pull/225 — 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/1212