[coverage] Conformance findings: CLOUDFETCH-019

Comienza con la prueba fallida test_invalid_client_side_cloudfetch_knob_value_does_not_fail_session_open en el diff del PR de cobertura bajo tests/ y, a continuación, rastrea el manejo de las opciones Thrift de CloudFetch del controlador de Python. Reproduce los valores no positivos y demasiado grandes, y verifica que la consulta se realice correctamente con al menos una fila, que la configuración no válida esté ausente de OpenSession y que CloudFetch siga descargando datos.

Summary

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

Findings

• CLOUDFETCH-019 [thrift]: Thrift backend forwards a non-positive max_download_threads unvalidated to ThreadPoolExecutor(max_workers=0), so the first CloudFetch-sized query raises ValueError: max_workers must be greater than 0 instead of warning and degrading to the driver default of 10
  • failing test: test_invalid_client_side_cloudfetch_knob_value_does_not_fail_session_open (see the coverage PR diff under tests/)
• CLOUDFETCH-019: Thrift backend forwards a non-positive max_download_threads unvalidated to ThreadPoolExecutor(max_workers=0), so the first CloudFetch-sized query raises ValueError: max_workers must be greater than 0 instead of warning and degrading to the default of 10 — a cosmetic client-side tuning typo breaks querying outright

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-python; 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