You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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-018 [sea]: A permanently-failing CloudFetch link fetch (403 on GET .../result/chunks/{n}) never returns: after 32 attempts the failure is logged and a waiter woken, but it is never recorded as terminal provider state and end-of-stream is left unset, so the drain blocks past 180s with 0 rows instead of raising a terminal error (kernel [PECOBLR-1143] Implement telemetry Phase 4-5: Export infrastructure and opt-in configuration #319; the pure-Go Thrift path conforms, giving up in 35s after 5 attempts)
failing test: TestLinkFetchFailureSurfacesATerminalError (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.
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-go; the reference PR is for cross-referencing the intended behavior, NOT a change to this repo.
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
TestLinkFetchFailureSurfacesATerminalError(see the coverage PR diff undertests/)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:
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).
Expect the drain to raise -- not to block, and not to report a clean
end-of-stream over a truncated row set.
(end-of-stream or the same error), not hang.
Expected (per the shared spec):
Context