[coverage] Conformance findings: CLOUDFETCH-019

Commencez par le test en échec test_invalid_client_side_cloudfetch_knob_value_does_not_fail_session_open dans le diff de la PR de couverture sous tests/, puis suivez la gestion des options Thrift de CloudFetch dans le pilote Python. Reproduisez les valeurs non positives et excessivement grandes, et vérifiez que la requête réussit avec au moins une ligne, que la configuration invalide est absente de OpenSession et que CloudFetch télécharge toujours les données.

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