[coverage] Conformance findings: CLOUDFETCH-012

Commencez par le test xfail du PR de couverture pour CLOUDFETCH-012 et par les chemins du driver qui gèrent les options de executeStatement et databricks.cloudfetch.enabled. Comparez le comportement attendu avec le PR de référence 225, puis suivez les requêtes ExecuteStatement et CreateSession de SEA/kernel. C’est terminé lorsque le contrat est respecté : INLINE et ARROW_STREAM sont utilisés, can_cloud_download est absent, au moins une ligne est renvoyée et il y a zéro appel à 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