GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — [coverage] Conformance findings: CLOUDFETCH-018 · Issue #945 · databricks/databricks-sql-python

[coverage] Conformance findings: CLOUDFETCH-018 #945

New issue
Copy link
New issue
Copy link
Open
Open
[coverage] Conformance findings: CLOUDFETCH-018#945
Copy link

Description

@peco-engineer-bot
peco-engineer-bot
bot
opened on Sep 6, 2026
Issue body actions

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 Customization to allow customization of OAuthManager to use another logic to open the login screen in browser #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

Activity

  1. KinjalGoswami68 commented on Nov 1, 2026

    @KinjalGoswami68
    KinjalGoswami68
    on Nov 1, 2026
    More actions

    Hey can i pick this up for thrift? or is engineer-bot handling it. planning to repro it first with a unit test that fakes a FetchResults failure

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.