[coverage] Conformance findings: CLOUDFETCH-019

Comienza con TestInvalidClientSideCloudFetchKnobValueDoesNotFailSessionOpen en el diff del PR de cobertura bajo tests/ y, a continuación, sigue el manejo de la opción Go CloudFetch y la ruta de solicitud de sesión. Ejecuta la prueba contra databricks-sql-go y confirma que los valores no válidos y los que superan el máximo producen al menos una fila, dejan ausente el campo de solicitud de protocolo relevante y satisfacen las aserciones de descarga.

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

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-odbc/pull/231 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-go; 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/1242