[coverage] Conformance findings: CLOUDFETCH-018

Comienza con el test xfail test_link_fetch_failure_surfaces_terminal_error en el diff del PR de cobertura bajo tests/ y luego compara el comportamiento previsto con el PR de referencia #322. Ejecuta el escenario del protocolo con un resultado en varios chunks y un fallo persistente de Thrift en FetchResults. Se considera terminado cuando el primer drain lanza una excepción en un plazo de 180 segundos y un drain repetido devuelve rápidamente un error o el final del flujo.

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-018 [thrift]: A permanently-failing CloudFetch link fetch (Thrift FetchResults) never surfaces a terminal error: the drain hangs indefinitely (>180s) instead of failing, stranding the application thread. The link fetch fails before any per-chunk state exists, so error handling keyed on per-chunk download/processing state never records the failure or wakes waiters (same class as kernel #319 / audit finding H03).
  • failing test: test_link_fetch_failure_surfaces_terminal_error (see the coverage PR diff under tests/)

Reproduce & Expected

CLOUDFETCH-018 — A permanently-failing CloudFetch LINK FETCH must surface a TERMINAL error to the consumer, and must do so in bounded time.

Reproduce:

• Enable this run's protocol scenario (see protocol_scenarios above) so the
  link-fetch call fails persistently. The result must be large enough to span
  MULTIPLE chunks, so the driver has to ask for links it does not already hold --
  otherwise every link arrives inline, no link fetch is issued, and the injected
  failure never fires (the protocol guard below catches that vacuous case).
• Drain a multi-chunk CloudFetch result whose link fetch fails permanently.
  Expect the drain to raise -- not to block, and not to report a clean
  end-of-stream over a truncated row set.
• Fetch again on the SAME result after the terminal error. Must return promptly
  (end-of-stream or the same error), not hang.

Expected (per the shared spec):

• full assertion contract:

result:
- label: first_drain
  exception_thrown: true
- label: first_drain
  elapsed_seconds_range:
    max: 180
- label: repeat_drain
  either_condition_true:
  - row_count: 0
  - exception_thrown: true
- label: repeat_drain
  elapsed_seconds_range:
    max: 30
protocol:
  thrift:
  - label: first_drain
    call_min:
      method: FetchResults
      min: 1
  sea:
  - label: first_drain
    call_min:
      operation: FetchResultChunk
      min: 1

Context

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